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:

[Anonymous Coward]

Yes - I'd love to code in an easy language for linux. And while I'm at it, I'd like it to work on windows, and on Mac OS, and it would be cool if it worked on all Unices, and it would be cool if I could do ActiveX and browser plugins.

Pause....

Oh - wait - I already can - I already have - and its simple - and its C++.

Cough...Qt...Cough.

No really - seems like everybody is being quite imbecilic. Gnome/Eric Raymond/everybody is so worried about Qt's commercial cost. Catch a clue. Free development couldn't be easier - anybody even trying the Qt API loves it. Commercial development is not in danger of patent infringement. Qt costs a little - sure - but it is a one time cost - not too much to ask.

Anyway - same old arguments - still a lot of deaf ears though.

Paul Seamons

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

[gerddie]

I agree with you, that C++ is a good language, however, QT has it's disadvantages. From the Gtkmm FAQ:

Why not just use Qt if you like C++ so much?

gtkmm developers tend to prefer gtkmm to Qt because gtkmm does things in a more C++ way. Qt originates from a time when C++ and the standard library were not standardised or well supported by compilers. It therefore duplicates a lot of stuff that is now in the standard library, such as containers and type information. Most significantly, they modified the C++ language to provide signals, so that Qt classes can not be used easily with non-Qt classes. gtkmm was able to use standard C++ to provide signals without changing the C++ language.

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

[maxwell demon]

You forgot:

[] Desktop!? I use the command line exclusively.

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

[Anonymous Coward]

Free development couldn't be easier - anybody even trying the Qt API loves it.

I tried, I didn't like it. Bloatathon... and that fact that it relies on a pre-processor for all the signal/slots stuff. Yuck. It even declares its own STL-wannabe QStrings. What a mess.

I know KDE zealots think Qt is GOD, but none of them know their ass from their elbow, and their minds are clouded by drooling, rabid zealotry.

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

[Anonymous Coward]

hummm....I predict that in 2 weeks time someone will write a programming language in the opensource spirit called "a penguin suit".....any takers?

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

[Anonymous Coward]

How about all of the above?

Next week I will be coding badly in Mono ASM, Scheme, and C in a penguin suit whilst eating an banana upside down to make my desktop to look just like Windows. The Scheme code will work perfectly in an easy to use fashion and will do the placement of my terminal windows.

(Don't blame me, Coyboyneal is my boss.)

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

[Anonymous Coward]

They 'modified the C++ language'? How? I wasn't aware of a Qt C++ compiler, and that's the only way to modify a language.

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

[Z4rd0Z]

It's called moc, the meta object compiler.

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

[Anonymous Coward]

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

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

[Anonymous Coward]

Why no []from scratch Option? It seems soo popular these days! :-)

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

[zxqart]

I agree. I don't see why using hardware inefficiently is a good thing.

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

[Anonymous Coward]

I don't think C has much to do with it. I can boot my computer from Grub to the login dialog in six seconds. This includes loading device drivers, the C library and lots of other stuff, initalising the graphics card and loading the GUI libraries.

Six seconds.

It isn't Linux and it isn't Windows. It's booting on a bog-standard PIII 450, 8Gb ATA100 hard disk, no caching tricks or anything like that.

Six seconds.

I'm certain I can get that down to five or even four seconds with some more work.

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]

Yeah, GCJ is great, a simple "hello world" take 6mbs. Java its for servers, not for desktops.

Re:How about still using C

[Anonymous Coward]

Yes, C/C++ has it's issues, but how about it's performance advantages over bytecode languages like C# and Java? It could be a way do distinguish Linux desktops from the Microsoft world, by running natively compiled applications. Look at either OpenOffice or Mozilla. They are consistently two of the slowest to launch apps on my Linux system

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

[Anonymous Coward]

Why not go all out and use BBC Basic.

C# for me, if you dont want my apps, dont use them, there is plenty of people behind you waiting in line to take your place. Tard.

Re:How about still using C

[alienw]

Have you ever written a program considerably larger than "Hello, world?" If so, you would probably know why that's not such a great idea. Besides, hardware is cheap. Programmers are not.

Re:How about still using C

[alienw]

Don't underestimate Microsoft. Mozilla doesn't have monopoly power and billions of dollars; Microsoft does.

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

[Anonymous Coward]

It's like writing an editor less featureful than Pico, and yet it uses more RAM than Emacs!

You mean Vim?

Re:How about still using C

[Deusy]

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.

According to the consensus, around the time C# was announced by MS, C# was just Java with a few more keywords.

So make GCJ compile C#! Problem solved! Best of both worlds! A union of two houses!

Re:How about still using C

[Anonymous Coward]

But any piece of software with the word 'basic' in it is entirely too unfashionable for use in Linux.
The arguments here are semi-technical at best; it's really about your personal belief system.

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

[DrSkwid]

MS is fairly good at is putting together a consistent UI. Might be ugly as sin like WinXP's default, but it's consistent.

Open Explorer, press f3, find that file boy!

what a dog

Re:How about still using C

[0x0d0a]

Java/C#: Good for vertical market, custom, rapid-development work. If people have a problem with the performance, they can run out and buy a new computer, because there are only 30 people using your software.

C/C++: Good for horizontal market stuff. You don't have 50 million users having to run out and purchase new computers.

Almost all of the core GNOME apps (Evolution, etc) are written for horizontal market use, and should be C/C++.

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

[Xargle]

Oddly I've worked as a programmer for many years. Many many desktop applications. Lots of work on embedded systems.

Engineers should still seek beauty in minimisation and efficiency. It's as if you're trying to take all the fun out of it.

Re:How about still using C

[Anonymous Coward]

People always forget that the fastest desktop ever had its gui written in C++. Think different? Download BeOS and you'll know what I'm talking about! ;)

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

[leandrod]

> 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

References?

Re:How about still using C

[zeptic]

I've actually seen some quite usable applications created with this tool. It's not by Microsoft but it resembles XAML and is primarily for writing application on the PocketPC.

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]

You mean you are still 'stuck' WAAAY back in evolution... maybe you can be the next "Neandrethal 'C' Man"!!

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

[IamTheRealMike]

Alright, points one and two are valid, especially the one about garbage collection causing swap (and cpu cache) thrashing. I'm not really sure about one though - dangling references in any language is a bug and there's nothing the runtime can do about it. OK, so in Java you use up lots of memory - if you'd freed that window in C or C++ a crash is one potential outcome which is much worse.

The other points you raise (memory overhead, startup time) are mostly due to the Sun JVM implementation - both Mono and GCJ apps have startup times similar to native apps. In fact I have written small programs and utilities using GCJ and they perform similar to native apps - not surprising given that this is exactly what they are.

GCJ with Java-GTK outputs binaries similar to GCC with GTK, or G++ with GTKmm. Their performance characteristics are naturally similar as well.

Re:How about still using C

[Anonymous Coward]

But C does have alot to do with it. Just imagine boot you system using Java! It will take 6 hours.

Re:How about still using C

[Anonymous Coward]

Oh, that bitch is slow. It just makes you feel good but it is slow.

Re:How about still using C

[master_p]

Use Qt then.

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

[GnuVince]

How about still using Assmbly and not needing a Thunderbird 1GHz to run a GTK+ application? Why not develop a GNOME computer chip where GNOME would run directly off metal and get real performances?

Using C# will not make performances that much worse, because they intend to write mostly GUI program which spend 90% of their time idling, waiting for user input. Are you telling me you want your idling time to be optimized?

The bottom line is that C# is a high-level language and C is just a portable assembly. What does that mean to developpers?

• Faster development time: no need to hunt memory allocation bugs, pointer arithmetic problems, no need to reinvent standard stuff all the time. It also means that as a hobbyist developper, you can do more from 20:00 to 22:00 before going to sleep than in C.
• Reduced complexity: the programmer focuses only on the problem at hand, not on the machine-sepcific details as well
• Less security issues to worry about: no buffer overflows
• Less headaches: did you forget a star before a variable to derefernece your poiunter?

Users also experience benefits:

• Applications come out sooner, so less waiting time
• Applications have a whole family of bugs that cannot happen, so more stability
• More portability: if the VM runs on two platforms, it's pretty sure you can run the application on two platforms too.

Everyone benifits from the GNOME people using Mono/C#, and I don't think many people run a desktop GUI on their Pentium 133MHz, especially not GNOME. GNOME does not need to suit EVERYONE and work on every machine, that's just too limiting. If you want a light window manager, use Blackbox or IceWM or twm or fvwm2. The GNOME people don't have "being able to run on a 7 year old computer" up on their list. They do have "improving the quality of our software" and "giving users a great desktop experience".

For all those who think everything should be coded in C for speed reasons, I invite you to search Slashdot for the interview with Chuck Moore (of Forth fame) and go here to read interviews with the guy. If you find agreeing with him, you are stuck in the 60's-70's. If not, you might reconsider your position on the usage of byte-compiled, high-level languages for user applications.

Vince.

Re:How about still using C

[Anonymous Coward]

"a crash is one potential outcome which is much worse."

Why? If a java app(let) throws an exception and stops responding of doing what the user expects it to do, does it really matter whether it "crashed" or just threw an exception?

In some cases, a crashed C++ app gives the user better feedback than a java app would, because at least he knows something went wrong - the window disappeared and Dr. Watson popped up. With a java app, it's possible to catch all those exceptions, and quietly misbehave without the user ever suspecting that something went bad.

Or even when the exception doesn't get caught, it gets printed to some hidden window you have to know the location of, before you can figure out whether the java app(let) crashed or not. The UI may still be responsive, but if the back end logic is no longer running, who cares whether it crashed or not?

Unfortunately, the Sun JVM is what everyone runs these days. Either that, or the Microsoft JVM, which they're trying to get rid of as quickly as they can. And GCJ is still using a garbage collection runtime, which as the original poster pointed out, thrashes swap. This is something fundamental to all GC'd platforms. But still, I'd love to see GCJ supplant Sun's JVM as the preferred platform for delivering java.

Because when Sun is complaining about the memory footprint of its own JVM, and nothing gets done, you know you're dealing with a company that just doesn't give a s*** about anything. What chance do we mere outsiders have?

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

[Anonymous Coward]

Now really, we have to think about this from a human-computer interface perspective. Microsoft has developed Visual Basic and XAML for a reason: they are easy for a non-programmer to use. That is the only reason they exist. Linux needs a similar language that is really great for prototyping. M$ thinks it is an XML based language. It probably is. Add a GUI toolkit to drag and drop widgets to write XML and it's even easier. Then anybody, non-programmers or budding programmers, can write something that will run on Linux.

This doesn't mean that it should be the only language. On the contrary. What is good for the human is not necessarily good for the computer. It will be horribly slow, involving lots of layers of code between the human and the computer. This is great for prototyping, but not for real apps. No, you need some other language which is fast. C++ has always been good for this (thus M$ still makes Visual C++). C would of course be the fastest, but it's a lot harder to manage for large projects. So I'd vote for C++ for this one.

There can't be only one.

John

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

[GnuVince]

But C lacks many features that becoming increasingly important to make dynamic, featured applications. I can think about first-class functions/methods, introspection, etc. You can have those in C, but only if you follow Greenspun's Tenth rule ("Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.")

Re:How about still using C

[Anonymous Coward]

Congratulations! You've just given a marketing spiel for XAML.

The whole point of XAML is to separate GUI design from code, so developers can write code, and UI people can put the interface together.

Re:How about still using C

[Anonymous Coward]

References? How about you run IceWM, WMaker and Metacity, and take note of the resident (RSS) memory usage for each, YOURSELF?

Then despair. Utterly. Metacity is one of the most sloppily programmed open source tools around.

Re:How about still using C

[Anonymous Coward]

Not true. The JIT can find patterns in dynamic code and optimize in ways that compile-once can't. Also the JVM can allocate objects from it's stack faster than the kernel can.

Re:How about still using C

[Anonymous Coward]

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.

Like French? ;)

I don't write much software, but anything that could make it easier would be welcomed.

I would say that you have different needs from those who do write a lot of software. When you devote a lot of time to it, you're willing to trade some amount of ease for flexibility.

Re:How about still using C

[johnnyb]

Not really disagreeing with you (although I see no reason to replace C with C++ - might as well go to a real language like LISP or Python), but the real reason that most companies switched to C++ is Microsoft. COM is only documented well in C++. Since Microsoft's compiler is essentially a C++ compiler (it may have a C-mode, can't remember), people code with the C++ extensions. So, some people claim to be writing C++ code, but it's really just spiffed up C.

Re:How about still using C

[Anonymous Coward]

I haven't had a memory leak problem in years in Java, it's just too simple to avoid.

Heh, I could say the same thing about C++. In fact, I have.

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

[Anonymous Coward]

You've clearly never spent hours tracking malloc arena corruption

Why don't you let him tell you what he's done and what he hasn't, instead of having you make assumptions out of thin air?

Just because you're not competent enough as a C programmer to prevent and fix heap corruption and other programmer-errors doesn't mean the language is unfit for the use of others.

Personally, I write code that does not corrupt the heap, and when by some goof on my part it does, a good debugger (and valgrind, etc) will show me what is wrong fairly easily.

Re:How about still using C

[Anonymous Coward]

The man said Pico! P I C O.

Why are you VIM wankers always pushing that thing?

Re:How about still using C

[Anonymous Coward]

He was making fun of vim, jackass.

Re:How about still using C

[xpl_the_myst]

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.

Writing applications in Mozilla doesnt mean they will work only on the 10% machines that have Mozilla. They will definitely include the mozilla libraries as a dependency or probably just bundle it with them. It's a non-issue.

Re:How about still using C

[torpor]

this is such garbage.

i can do everything in C that any moron with their 'whiz-bang-language-of-the-month' can do, and someone cooking half-baked rules about their observations won't change that.

Re:How about still using C

[bulletman]

I'm not a full time programmer, but here's my question:

What about ditching swing and using java bindings to the UI toolkit? If the toolkit were written in a compiled language, wouldn't the performance be great? I know that PyQT and PyGTK apps are very quick.

Stephen

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

[IamTheRealMike]

You've clearly never worked on the sort of codebases I have then...

Re:How about still using C

[torpor]

C may not be the Windows development language de jour, but I even find it hard to conceive that someone could think that 'nobody writes C Windows apps any more'. in my business (audio software) there are still plenty of very avid, very professional, just-as-good-as-'easier'-language-projects apps being built ...

if you can't use C to write a desktop app, something is very, very wrong with:

a) your attitude about development
b) your installed operating system
c) your methodology

look, it doesn't matter. use whatever floats your boat. but just don't go around parrot'ing some absolute line about nobody using C any more, for 'desktop' apps, because it simply isn't true.

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]

I don't know, I heard that QT eats babies.

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]

GCC compiles per file. It doesn't compile the project as a whole,

The GNU toolset includes an auxiliary program which enables GCC to compile a whole program as one unit. It is named "cat".

Re:How about still using C

[Anonymous Coward]

My Metacity uses 7504 KiB of RSS memory right now.
I'm using Fedora Core 2 Test 1 + Rawhide.

What's the big deal?

Re:How about still using C

[Minna Kirai]

There are some things you cannot know statically.

Your examples about the supposed "limitation of static analysis" are actually merely the "limitations of dumb linkers". Many C++ programs still use C linkers (for compatibility reasons), so these problems occur. But there is nothing inherent to static analysis which forces this. Using a smart C++ linker could catch all those cases.

Re:How about still using C

[GnuVince]

Not garbage at all. Try one of the following:

• Write a dotimes operator in C. Usage is dotimes(int i, 10) { printf("%d\n"); } and it will print 0 to 9. Beware of inadvertant variable caputres and multiple evaluation (if the second argument is x++ for example)
• In Smalltalk, I can do this: Smalltalk at: #MyClass methodDict values do: [:method | Transcript show: method getSource ] which will give my the source code of all methods of MyClass. Can you do it?
• I can do this: myArray := #(1 1.5 $a 'Hello world'), can you do it?

The fact is, there are many C cannot do itself. You can explore the alternatives (Smalltalk, Lisp, O'Caml, etc.) and understand or just live in your little dream world where C can do everything, even if that statement is false.

Re:How about still using C

[Anonymous Coward]

As far as virtual methods go they are far more used in Java since every method is virtual. In C++, functions have to be explicitly declared virtual. So in C++ if a virtual function is not needed the programmer does not need to declare and I would think a good compiler would be able to do away with an unneeded vtable.

As far as inlining goes, C++ is always going to inline more code than Java static or otherwise. Java's dynamic class loading structure prevents a lot of obvious inlining.

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

This might be true in theory but as far java is concerned the type information and program structured is too far gone in java bytecode to be of any great value.

In pseudo-dynamic systems like Java, JIT is important because the compiler can't do a lot of the obvious optimazations during compile time so the optimazations are only possible during runtime hence the desire for JIT. The sad thing is most Java programs use a static set of classes from beginning to end-> meaning they could be optimized at compile time if Java was structured differently.

Re:How about still using C

[mrogers]

Speaking as someone who tried to write a small window manager for Gnome and failed, I think Havoc's done an excellent job with Metacity. If you think it's too bloated you can always try hacking Gnome support into wm2. It ain't as easy as it sounds.

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

[abigor]

Nothing to do with "can't" - drop the superior bullshit, please. I wrote C apps for nearly ten years, for Windows (since 3.1 to Win 2000) and Unix (HP-UX, AIX) so it's not like I'm some bandwagon jumper.

Granted, in your extremely limited area, sure, some people are writing C desktop apps. I shouldn't have said "nobody", I guess :) But in the mainstream app world, it's just not getting used. Windows and Macs are the desktop. On Windows, it's C++. On the Mac, it's Objective-C. With KDE (the leading Linux desktop), it's C++.

But granted, there are exceptions.

Of course, C is everywhere in the systems world (my world, these days).

Re:How about still using C

[Minna Kirai]

Almost all of the core GNOME apps (Evolution, etc) are written for horizontal market use, and should be C/C++.

The strongest complaints against GNOME adoption is not that it is slow, but that features are lacking. Therefore if a different programming language would allow faster correct development, it would be overall beneficial, even if there is a performance hit.

Re:How about still using C

[Anonymous Coward]

Mozilla doesn't have monopoly power and billions of dollars; Microsoft does.

Yet their browser sucks compared to Mozilla. Just spend an evening surfing porn with IE, and you'll know what I mean.

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

[Anonymous Coward]

"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

...including Common Lisp.

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.

Re:How about still using C

[Z4rd0Z]

It seems reasonable to use gcj, but it doesn't really fit the need for a high level, managed environment. If the code isn't running on the vm, it's not managed, right?

Re:How about still using C

[Anonymous Coward]

Most of the things you just pointed out as
being bad apply equally as well to server
side Java. So the question is, if you don't
want it for your desktop then why do you
want it for you server side apps?

Re:How about still using C

[pellaeon]

But having to buy fast hardware for all the users running that programmer-friendly program in order to have these users even slightly productive is the most expensive option.

Face it, programmer time spent optimizing apps is time well spent. That includes language selection.

Re:How about still using C

[AndyS]

Not (totally) true. Some values might be read from a disk file, and then kept around. A jitter could determine that this value was constant after being read in and generate code that completely ignored the branch in the first place.

But yes, compilers/linkers could do with some improvements to eliminate a large number of cases that they do worse than virtual machines

Re:How about still using C

[Anonymous Coward]

Note how the parent (which is bashing Java)
is moded 5 and this rational and reasoned
response showing how the parent was wrong
is moded 3. Yep, those Slashdotters are always
seeking out the truth.

Re:How about still using C

[torpor]

good lord man, why on earth would i want to introspectively inspect my source code in a running, professional, working application?

no, never mind ... i don't want to know the reasons. sounds crap to me!

(hey, i can do (void *)(void *); good enough!)

Re:How about still using C

[jovlinger]

Or you can use the excellent wmx theme for sawfish.

Re:How about still using C

[torpor]

Ermm... I know tons of Mac OSX apps that are written in just pure C too, so just get off your smart box, or bandwagon, or whatever it is ...

C is still in active, professional, hard-core, targetted and mass-market use and will probably stay that way for a long while yet. C is still a very, very, very useful programming language and the only reasons to get rid of it are purely political and/or utter bullshit.

Re:How about still using C

[AndyS]

Actually, I'd wager Java inlines more code. C++ won't inline code across functional boundaries - if you compile x.cc and y.cc then it won't inline a call in x.cc to y.cc (you get the basic picture).

I briefly remember reading about Java runtimes doing 'dangerous' optimisations and then rejitting bits that change. A fairly hairy idea, but potentially capable of some impressive improvements.

Finally, there is immense amounts of type information in Java bytecode, as has been shown when people reconstruct source from it.

Each method call (which has to be declared in the class file), says in it's signature what it returns, and the verifier relies upon this type information in the bytecode to determine what values things are. Local variables aren't really preserved as such, but you can check the type of pretty much everything.

Re:How about still using C

[mrogers]

IIRC, wm-spec-list is on gnome.org because its original focus was on getting Gnome window managers to co-operate with taskbars and pagers, handle multiple desktops in a standard way etc. KDE had a standard window manager so it wasn't an issue. Now Gnome has a standard window manager too, so the whole thing was kind of unnecessary. But i suppose the window type hints are useful to someone. :-)

Re:How about still using C

[Compenguin]

I don't see how it's better than the situation with c. C lets you choose on an object by object basis if you want it garbage collected or if you want to manually manage it.

Re:How about still using C

[AndyS]

How is it not managed? You can't trash memory by overwriting bounds, you can't crash the entire app by dereferencing null....

(excluding if you link it with C++, but then that can bite VMs in the arse as well)

Re:How about still using C

[GnuVince]

If you can't see the good, you are doomed to program static applications are your life, while I can add things to a running application. That's right, my application is running, I decide to add a functionality. I code it, and POOF it appears on my applicaiton and it works. No need to stop the application, no need to do a big recompile. You seem to be just as blind as Chuck Moore.

Re:How about still using C

[Z4rd0Z]

Maybe I misunderstood the term "managed code", but I thought it meant the code was running on a virtual machine. For example, Microsoft now has what they call managed C++ which runs on the .NET vm.

Re:How about still using C

[FooBarWidget]

Yes let's completely forget that the reported RSS memory usage also includes shared memory.

Re:How about still using C

[misleb]

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.

Then explain why Java GUI applications/applets are are so notoriously unresponsive, slow to redraw, and ugly on all platforms. Maybe your SWING application is different, but somehow I doubt it. Java has no place on my desktop.

-matthew

Re:How about still using C

[Trejkaz]

I guess that explains how Java beat out every other language in various benchmarks a couple of months ago. The only area it was slower in was trigonometry so unless you are using sin() and cos() a lot, your C++ will be slower than Java. :-)

Re:How about still using C

[pyrrho]

>In C, you can easily leak four bytes at a time, and good luck finding it.

you can easily use a debug version of the libraries that will tell you if there is a leak when you exit, it can tell you where the memory was allocated, and if the memory was overwritten.

Most of your answer is just "hey, you are just not good enough at Java"... while I cannot defend the parents skills with Java, I can that dumping the heap and writing scripts to analyse the output is not "not having to worry about memory". There is nothing wrong with that (quite the opposite, it shows your willingness to take the steps nec. to make a good product), but you also have to take into mind the time it took to get that expertise. You may have written those things in one hour (or was that one hour "programmer time"?), but you must also count how much time did you spend becoming familiar enough with that output to be able to write that in one hour.

I think Java has a lot going for it although I have only done limited work in it. However, I bristle at the idea (which you did not advocate but which is often heard) that somehow the answer to good programming isn't detailed, that memory issues are abstracted away, good programming does come down to things such as you have learned... how to make your VM dump memory and looking very closely at how you use memory.

OTOH: we have a java application which has been praised by a user that is still on OS/2 (don't ask)... try that with C/C++.

Re:How about still using C

[Anonymous Brave Guy]

If you're thinking of the same study I am, then as usual, it was deeply flawed. Performance on small code fragments exercising specific areas of a language in repetitive ways is rarely a good basis for benchmarking, and the fact that nearly all language comparisons seem to fall into that category tells you something about how much an average language comparison based on benchmarks is worth.

Oh, it was a joke... D'oh... :o)

Re:How about still using C

[Trejkaz]

Yeah, it's probably the same study. It would have been more interesting to see their performance graphs so it would be possible to tell if garbage collection is kicking in at all during that time.

Either way the problem with Java isn't the speed, it's the way all the current popular implementations are memory hogs. Not every JVM is like that though, some of them are quite small, just that nobody seems to give a shit. Also if you use a constrained set of libraries you can probably get away with using GCJ, which doesn't seem to use much memory either.

Re:How about still using C

[Anonymous Brave Guy]

i can do everything in C that any moron with their 'whiz-bang-language-of-the-month' can do

So can I. I've programmed C for years.

But I could do it with half as many bugs in C++, or write it five times faster in Haskell.

Re:How about still using C

[Anonymous Brave Guy]

I think you're missing the point. What you wrote is a feature comparison, not a comparison of the results (functionality) you can achieve.

If you wanted to, you could write an interpreter to do any of the above in C. Such is the power of a low-level language.

Of course, it would just take more time and effort than using many of the alternatives. Such is the limitation of a low-level language.

Re:How about still using C

[Anonymous Coward]

Why natively compiled code more legible than bytecode compiled code? We are not talking about interpreted languages.

gcj is definitely not fast compared to C/C++ generated code. Is that because java is just badly designed for natively compiled code or that the power provided by java/c# are not suitable for compiled code? garbage collection only should not bloat and slow down a program so much.

Re:How about still using C

[Anonymous Coward]

Debugging? memory leaks? Why don't you think before you code? ;-p
I have coded full time in C since 1988 and have never seen memory leaks or bugs as a problem. Maybe people who can't code should not? Maybe the "don't worry its fixed for you" tools are a bad idea?
And Java... God what crap. I found a bug in String. What to do? Well is OO, Ill just fix it. What? 'final' on String?!?! "Is this OO?" I asked myself as I tossed the code and re-wrote it in perl.

Re:How about still using C

[Anonymous Coward]

For me as a user, I often get annoyed at programs that do their UI well, but have horrible functionality.
-An once of looks is worth a pound of performace.
-To an idiot.

Re:How about still using C

[alienw]

That's exactly my point. They may have an inferior product (MSIE), yet they still have huge marketshare.

Re:How about still using C

[alienw]

But having to buy fast hardware for all the users running that programmer-friendly program in order to have these users even slightly productive is the most expensive option.

How fast I can write a text document is determined by the speed I can write, not the speed of my word processor. It makes no sense to have lightning-fast desktop applications (that spend 99.9% of the time in the idle loop waiting for user input) at the expense of increased amounts of bugs and general lack of features. As long as my word processor runs more or less fast (i.e. doesn't take more than 30 seconds to start and doesn't bog down the system too much) it's fine.

Face it, programmer time spent optimizing apps is time well spent. That includes language selection.

Correct. That's why you don't write it in C, but instead use a more high-level language that lets you write a more reliable and featureful program, perhaps at the expense of a negligible speed loss. If what you said was true, we should all be writing apps in assembler because it's slightly faster.

Re:How about still using C

[wastingtape]

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.

I think you're confusing a graphic designer with an artist. A designer is concerned with communication. An artist is concerned with aesthetics.

While either would help a project, i think ultimatly a psychologist would best be employed in UI design to help understand a user's thoughts while operating the software.

Re:How about still using C

[cheesybagel]

I have programmed both on C and C++. Reasonably sized , over 10K lines of code, projects. C++ has several flaws and does not fix most of my issues with C. More, it adds several annoyances of its own.

For one, object orientation is not a productive programming paradigm for most things. Sure it works well for GUIs and other types of visual programming, but not everything fits neatly into that role model. What if I want to do event based programming, or procedural programming for example? The template support helps somewhat, I actually enjoy that style of programming more than object orientation, but the language support for template style programming is fairly poor. This is partly due to the static nature of C++.

Another problem is that C++ promotes sloppy programming. Good programming should separate interfaces from code. C++ has things like the class declarations with code inside, which are just plain nasty.

The main problems of C are due to memory handling issues. Overruns, unassigned pointers, etc. C++ is hardly an improvement on this matter.

Re:How about still using C

[NonSequor]

It's just that Lisp and other languages you can do some things that you can't do in C/C++ without implementing some sort of interpreter, virtual machine, or just-in-time compiler. For example, in functional languages you can define functions at run time. In Lisp, code can be generated easily since function calls are expressed in terms of lists.

Re:How about still using C

[Wolfier]

> Once you code enough, it all starts to look
> similar, anyway.

And a couple of years after that, they'll start look different again.

Re:How about still using C

[Anonymous Coward]

Read this
http://www.idiom.com/~zilla/Computer/javaCbe nchmar k.html
and then tell be you still think Java is slow.

Seems like every kiddie on the block who has never used anything above JDK 1.3 thinks Java is interpreted (like 1995) and slow.

BTW use the -server switch when benchmarking.
Lots of Windows guys like to do C# vs Java benchmarks using the (slower) client JVM.

Re:How about still using C

[Moraelin]

I've been programming for some 10 years in C, and then some 5 years in Java. (Plus one year before that of playing with Java at home, on my free time.) Not small stuff, either. I'm talking hundreds of thousands of lines programs in both cases. So let's please drop the "if you disaggree with me, then you're obviously inexperienced" arrogance already.

Yes, occasionally I'd get to spend a day or two chasing a memory leak. (Ironically, never in UI code.) But then I had a program which worked well and fast. Which is more than I can say about any Java GUI programs I had to work with.

There are situations when you might wish you had a GC in C, but those usually involve complex graphs of objects pointing to each other. Most problems aren't like that, though.

Then I moved to Java. Now instead of occasionally spending a day or two debugging a memory leak, I had months of tuning the performance to be acceptable.

Everyone wrongly thinks of desktop apps as stuff that just spends 99% of the time waiting for the user to type the next letter, so performance doesn't matter. Wrong.

Even if on the average that's the case, there comes the moment when the user asks for such stuff as spell-checking a 20 megabyte document. Or recalculating a horribly complex spreasheet, which requires several passes. Or applying some complex filter on an image, fast fourier transforms and all. Or whatever else.

That's when he/she'd rather not wait 3 times longer than strictly necessary.

Re:How about still using C

[Moraelin]

That's an easy question to answer:

1. Server-side programs are long lived. A servlet runs in a JVM that's started once and runs happily ever after. (Well, not ever after, but at least days.) So the few seconds of extra startup time only happen once, and the user never sees them. Which is more than I can say about small utilities written in Java.

2. Server-side programs spend 90% or more of their time waiting for the database server. Hence, java's performance problem doesn't really matter. You could still write 10 HTML pages in Java before the database server gives you the data for one. Java is not the bottleneck there.

3. Server-side programs don't have a Swing GUI. 'Nuff said.

4. For that reason, they don't have a memory leak problem with listeners, either.

5. The swapping issue is less important for servers, since those tend to be big machines with lots of RAM. If a website requires 256 non-swappable MB all by itself on the server, that's peanuts.

By contrast, if a desktop program requires 256 non-swappable MB all by itself on a user's home machine, that's ludicrious. That user might have 256 MB total RAM nowadays. Given that any OS (including command line Linux without X loaded) takes _some_ memory for itself, that already pushes the user's machine in a thrashing frenzy.

(Thrashing means: Each swap page is loaded, checked, then discarded to make room for loading and checking the next page. Repeat ad nauseam. Your HDD LED stays bright and your machine makes funny grinding noises.)

Re:How about still using C

[torpor]

I can do that in C. No need to recompile, no need to stop the application, nada.

Next.

Re:How about still using C

[torpor]

Okay, I get it now. You're just a totally crap C programmer.

Re:How about still using C

[Anonymous Brave Guy]

Read this [link] and then tell be you still think Java is slow.

I didn't say Java was slow; modern Java is effectively a compiled language with similar features to C++, and so you'd expect that ultimately they will have similar performance for much realistic processing. The quality of implmentation (how good the static optimizer is in C++, or how efficient the GC is in Java, for example) is likely to be the deciding factor in the long run; a good optimising compiler can produce code several times faster than a bad one, even using the same language, and the differences between Java and C++ are probably well within those error bounds for most purposes by now.

I was simply pointing out that the benchmarks to which the OP appeared to be referring -- which, unlike some of the ones you cited, were very short code fragments -- were flawed as a basis for comparing the speed of code produced by different languages.

Re:How about still using C

[Anonymous Brave Guy]

Given how you seem to look at things, I can understand that you'd prefer C to C++, and of course there's nothing wrong with that. I'm all for using the right tool for the job, and familiarity and mindset are big factors in what's "right".

However, I feel obliged to "defend" C++ a little in light of your comments. No-one is forcing you to use the OO features in C++, and indeed many of the language's key architects have written at length on how one of C++'s big strengths is that you aren't constrained to a single programming paradigm.

That said, I have worked on relatively large projects (millions of lines) in C++, where a fairly heavily OO design was used, and it certainly has its moments. You don't see a lot of this with toy projects of a few thousand lines, but when serious scalability becomes an issue, good use of modular programming really tells, and C++ provides many more tools to support modular programming than C does. I was working on almost entirely back-end code, BTW; this wasn't GUI stuff, but low-level instrument control and some reasonably intricate maths. As with anything, object-oriented (or simply object-based) design has its place. Use it when it helps, and leave it when it doesn't. But your claim that OO is not a productive paradigm for most things seems to be totally unfounded. Similarly, the "sloppy coding" you mention is far more associated with Java or C# than C++: the latter allows you to put code inside or outside class declarations, as you see fit.

Finally, you're right on the money that most of the problems with C are due to low-level issues like buffer over-runs and pointer problems, but to claim that C++ is hardly an improvement betrays a lack of experience. Several of the basic idioms in C++ evolved precisely to overcome these limitations, and with some basic knowledge of good programming technique (I'm not talking guru, I'm talking having read just one or two good books) you should never have any of these low-level problems. C++ is a world ahead of C in this respect, and always has been; it's one of the major benefits of switching.

Re:How about still using C

[Anonymous Coward]

It's like writing an editor less featureful than Pico, and yet it uses more RAM than Emacs!

MS Word?</cheap_shot>

Re:How about still using C

[Anonymous Coward]

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

And then we still have the problem of having to match scripts and interpreters just as we now have to match binaries and platforms. Plus we have all the extra overhead of interpreting. I must be missing something - what actual advantage does your idea provide?

Re:How about still using C

[Anonymous Coward]

C lets you choose on an object by object basis if you want it garbage collected or if you want to manually manage it.

s/lets/forces/. That's after you've figured out the esoteric GC interface for whichever GC library you've chosen.

Life's too short to code in C.

Re:How about still using C

[Anonymous Coward]

hardware is cheap. Programmers are not.

Except in India, where the opposite is true.

Re:How about still using C

[Sax Maniac]

You're right, a cogntive psychologist is exactly what is need, though it's rare to be able to get that. UI designers should know some of the principles of it, though.

Perhaps I am confusing them. Both graphic designers and artists are typically only concerned with output-only presentation of static material. UI designers have to be concerned with that plus the two-way interaction, input and output, between information that is constantly changing.

Re:How about still using C

[leifm]

I didn't get the impression that XAML was an HTML replacement so much as a way to do Windows UI through markup. So I'd have to agree with XAML not taking over HTML.

Re:How about still using C

[cheesybagel]

Yeah, sure. I am not forced to program using an OO style in C++ if I want to. It still has C as a subset. But most C++ people try to force me into it, even if it makes no sense at all. But that is besides the point. The thing is, C++ does not fix the main problems of C. What it adds is a bunch of feature creep which is more often than not useless.

There is one thing that is mildly useful however. Namespaces. On C you usually work around that problem by adding prefixes to function names, but this is suboptimal.

Regarding C++ being much more suitable for large programs due to being more modular, well, not really. Besides namespaces, there isn't much that C++ can do and C cannot in that respect. C libraries are great and I personally have used them in most of my larger projects. They enable most of my module requirements.

The Linux kernel has 3 million lines of code and is written in C, with some pieces of assembly here and there. So here is one successful example for you. There are more.

Re:How about still using C

[Anonymous Brave Guy]

I am not forced to program using an OO style in C++ if I want to. It still has C as a subset.

It also has, for example, reasonable support for generic programming (at least when combined with a good expression template library), which is very much more powerful than anything in C, yet has nothing at all to do with OO. Just because a lot of people use C++ without bothering to learn it properly doesn't mean you should be influenced by them and try to make everything OK.

The same goes for your "C++ does not fix the main problems of C" argument: C++ does provide tools and idioms that very much address the major shortcomings of C, not least higher level tools to replace arrays and pointers almost universally. I don't see how you can possibly claim that C++ isn't an improvement in this respect; it's worth switching for the RAII idiom alone!

Regarding C++ being much more suitable for large programs due to being more modular, well, not really. Besides namespaces, there isn't much that C++ can do and C cannot in that respect.

I guess we'll have to agree to disagree on that one, then. I think classes and templates both provide an extra tool for abstraction that can overcome a lot of nasty design issues in C. You don't have to use them, but they're each useful in a wide range of situations.

The Linux kernel has 3 million lines of code and is written in C, with some pieces of assembly here and there. So here is one successful example for you. There are more.

I'm not claiming you can't write good code in C, I'm just suggesting that you can often write code to achieve the same result faster or with fewer bugs in other languages.

That said, I'm not sure citing one of the few "shining beacons" in the open source world helps your case. You're talking about a project architected by one of the most talented software developers on the planet, contributed to by many of the most enthusiastic and skilled programmers in the business, and supported financially by several of the commercial success stories of the OSS world. That combination would have produced a good result in any language; C is just the tool that was most familiar to those who were doing the job. And of course, C was pretty much designed for writing the UNIX operating system, so it's a particularly natural candidate for a UNIX variant, no?

Re:How about still using C

[LWATCDR]

While I have to agree that good C++ could most likley beat Java code the fact that Haskell beat the Java version makes me think the Java version of that sim was not well writen.

Java has it's place as does C++. For writing a database driven multi-treaded app Java is a nice tool.

Re:How about still using C

[markbthomas]

The Java version was well written. The problem was it made quite a bit of use of objects (each Event was an object). Unfortunately Java object creation has such an overhead the simulation was slow (and the flood of stale objects hanging around between gc runs made it a memory hog, too).

And if anyone says "well don't use objects, use a static mechanism or allocate manually instead" has missed the point: if you have to code Java like you code C, then you might as well be using C.

File selector

[dr.Flake]

This is not about the frigg.... file selector. It is OK now, so lets move along to the actual topic:

The future technologies behind the desktop.

Re:File selector

[Anonymous Coward]

Why are you pluralizing the word "sig" with an apostrophe? Also, it's not "more witty" but "wittier."

Re:File selector

[dr.Flake]

apparently you were fortunate enough to be born in an english speaking/writing country.

Now move on, and try to find more spelling mistakes on /.

You've just found your long awaited day-time job!

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?

[Cthefuture]

Yep, especially compared to Terminal Services on Windows. That works at the widget level though.

Maybe we need a high performance network enabled version of Gtk.

Re:Does the new release improve the X performance?

[Anonymous Coward]

Maybe we need a high performance network enabled version of Gtk.

The problem is not on Gtk. Gtk makes use of a double buffer to avoid flickering. That's not bad, but it brings an X Window design decission to the surface.

When using X over a network, it always transfers ALL the screen to the clients, even the static parts.

The addition of the XDamage extension to X servers allows the X protocol to transfer _only_ the screen changes over the network. Less transferred data, less network use, more speed.

I can't wait for the Freedesktop X server to be production quality.

Re:Does the new release improve the X performance?

[Anonymous Coward]

Even that won't be as fast as terminal services though.

Terminal services sends things like "Radio button at X,Y" in binary form it takes practically no bandwidth at all. The only time it sends raw graphical information is when it has to (like when showing an image). The widgets themselves don't get sent as graphical information. It's very fast.

XDamage sounds more like VNC and although VNC isn't that bad, it is quite a bit slower than terminal services.

Re:Does the new release improve the X performance?

[jcupitt65]

I think you're maybe confused: X over networks works at the "draw a line from X to Y" level. If part of a window is damaged, the client is sent the coordinates of the damaged area and asked to redraw it.

Re:Does the new release improve the X performance?

[iantri]

X alone is uncompressed; if you want good performance over wan/dialup/dsl you need some more stuff.

Nomachine makes a really awesome point-and-click X client thing for windows with a caching, compressing, X proxy on the back-end *NIX box. There's also *NIX clients, AFAIK, but the performance is supposedly similar to or better than Terminal Services. I tried it with their on-line demo Red Hat 9 machine and it worked pretty good over DSL. (On their end the machine is connected by a 256k DSL connection, last time I checked)

It's not free; but the components are GPL'd with the exception of the pretty client software, so if you're really cheap (and it's not that expensive) you could kludge something together..

There was a Slashdot article on it...

Re:Does the new release improve the X performance?

[jcupitt65]

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

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

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

Re:Does the new release improve the X performance?

[quantum bit]

The problem is not on Gtk. Gtk makes use of a double buffer to avoid flickering. That's not bad, but it brings an X Window design decission to the surface.

When using X over a network, it always transfers ALL the screen to the clients, even the static parts.

I'm not so sure it's really X's fault. Qt-based apps over a remote X connection on a LAN can be difficult to tell that they're not running locally. They're very fast, even when using pixmap and alpha-blended themes (Xrender at work?). Over a dial-up or slow network they're not exactly fast, but are generally still quite usable.

Gtk-based programs (2.2 anyway, haven't tried 2.4 yet ;) seem to be quite laggy even on a moderately fast LAN. Over a slow connection I usually give up and try to extract the data I need using the CLI if possible (though I've used gimp through Xvnc a few times because it was much quicker). Even using a theme like ThinIce it's still painful, especially redraws. Full-window drag seems to interact badly with gtk, I've seen it take 5-10 seconds just to redraw widgets LOCALLY after moving a window across.

I don't know if Qt does double-buffering or not, but I've never noticed any flickering. Not trying to knock gtk but it does not seem to be well-optimized for remote X connections.

Re:Does the new release improve the X performance?

[Colin Smith]

It isn't just compression, with LBXproxy and similar, Gnome apps are noticably poorer performing than Motif apps on similar operations.

Motif stuff over a wan/dsl/dialup can actually work usably.

Re:Does the new release improve the X performance?

[iantri]

Motif apps are graphically simpler and probably designed with efficiency in mind..

Re:Does the new release improve the X performance?

[Anonymous Coward]

So it is only fast on simple program which use standard widgets. You need to transfer pixel for pixel with customized widgets (like excel?)

Re:Does the new release improve the X performance?

[Colin Smith]

So you're saying that Gnome has been deliberately designed to suck?

Re:Does the new release improve the X performance?

[iantri]

No. Gnome was designed in an era in which efficiency was less important.

Re:Does the new release improve the X performance?

[maxwell demon]

and probably designed with efficiency in mind..

Isn't exactly that the point?

Re:Does the new release improve the X performance?

[Colin Smith]

Or... Gnome developers simply don't care that performance is poor.

Re:Does the new release improve the X performance?

[Anonymous Coward]

I say force 'em all to develop on 133MHz Pentiums. Things would probably shape up, then.

Re:Does the new release improve the X performance?

[Anonymous Coward]

Sometimes Terminal Server will use the "send compressed screenshots over the wire" method.

The trick is that in the real world, this is always faster than X's ServerStuff/ClientStuff division (which is fairly arbitrary and increases complexity). For a complex app (not Athena widgets which X was designed for), a bitmap may actually be smaller than a bunch of Draw X,Y commands.

Re:Does the new release improve the X performance?

[johnnyb]

The release notes for Gtk2.4 indicate that they have solved many of these problems.

Re:Does the new release improve the X performance?

[Minna Kirai]

It makes WAN/dialup/dsl use of X even more

I recently tried running Evolution (a gtk app, but not part of new GNOME) over a high-speed but long distance link. For a while it was barely tolerable. Sure, it took 4 minutes to startup (instead of 15 sec) because of the animated splash screen that clogged the pipe, but I got by that.

Then I dragged an email message into another folder.

70 minutes later I killed the process, as it was still hung up drawing a little email icon proceeding pixel-by-pixel down an animated path.

Re:Does the new release improve the X performance?

[spitzak]

This is wrong. The main thing Terminal Services does is compress the images when it sends them. Otherwise it works pretty much at the GDI32 level, sending commands like "draw a line" and so on that are equivalent to Xlib.

The main problems with X are:

1. The Xlib graphics library is extremely limited and primitive. It is physically impossible to draw a modern GUI with it, so lots of programs such as GTK revert to drawing an image locally and sending it. Now this is also true of Window's GDI32 but to a lesser extent (for instance you can draw rotated characters with it) so more Windows programs are able to use it to get the display they want.

2. X does not compress the images when sending them, so when things revert to images to get what they want, it is far slower than it needs to be. The attempt to do so (the XImage Extension) turned into a useless bloated over-engineered mess so that nobody used it (something which I'm afraid all Linux and Windows attempts to make a desktop environment are doing). I am unsure if Terminal Services compresses images, but I suspect it does. VNC definately compresses images.

Re:Does the new release improve the X performance?

[Virtex]

I occasionally run Evolution remotely across my cable modem (2Mb down, 384Kb up), and while it's a bit sluggish, it's not unusable. Maybe 30 seconds to start up, 2 or 3 seconds to bring up a message, etc. Scrolling through a message is pretty quick. It sounds like your network connection might have been dropping packets or just running really slow between you and the remote box. BTW, are you compressing your data stream? I run mine through a compressed SSH tunnel, and that helps out quite a bit.

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

[Anonymous Coward]

Yeah. Why should we ever do research into something new when we could just use the good old comfortable stand by. Nothing new can possibly be better. That's why I still use punch cards.

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

Re:Eeek...

[0x0d0a]

Well, let's just take a look here.

On Windows (what everyone's scurrying about and worrying that Linux is falling behind) we have:

* C (Win32)
* C++ (MFC)
* C#
* VBScript (dunno a damned thing about it)
* VB
* Java

On Linux, popular languages are:

* C
* C++
* php
* perl
* python
* Java

I'd say that there are about six on each platform. Really, not a huge difference. In addition, there are scads of less-used languages on each platform: Delphi, Ruby, ocaml, Pascal, Objective C, Ada...

This is not what you'd call an overwhelming number of languages on each platform. Furthermore, it's *much* easier to reuse GTK+ (C) knowledge with GTKmm (C++) than it is to reuse Win32 (C) knowledge with MFC (C++).

With libraries, there are roughly the same number in use. ClanLib is mostly a fringe library, same as Allegro -- SDL is quite dominant. Heck, there are a ton of libraries, but it's not as if the system is wildly different from the Microsoft side of the fence.

Re:Eeek...

[Anonymous Coward]

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

These things aren't buzzwords, they are things people are actually using.

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.

Use what you know, that is correct. I know C#, so I will write in C#. Thank you Mono developers. For GUI, I will use GTK (or QT) in the form of GTK# or QT#. I've been coding for 15 years, but I really must say, C# is where its at. This isn't about what is "trendy," its about what works well.

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

When the free software community can produce something better than C# I will gladly use it.

Re:Eeek...

[drooling-dog]

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

With the right tools, development with C++ can be a satisfying experience as well. I've written a couple of apps
with gtkmm (a C++ wrapper around GTK+) and found the experience similar to coding with Java and Swing. Aside from the convenience of garbage collection - the need for which is partly a function of your coding style and habits anyway - the appeal of Java is largely in the class libraries that come with it. The choice of class libraries can easily make or break your experience with C++, as well.

Re:Eeek...

[edsonmedina]

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.

Yes, so you can build more software with less resources (time/money). We all know that.

You can hire a few cheap lazy programmers and build stuff pretty fast instead of hiring some code gurus and take twice the time.
But in the end, the software will run much, much slower on the user than C/C++ does.

Wasnt the software supposed to HELP the user on the first place? Not the programmer nor the software house, but the USER.

C/C++ will easily be phased out as much as ASM was

ASM has never been phased out. Ever thought what a compiler outputs?

Not to mention game development where ASM is pretty much alive.

Being so loosely integrated is one of the major limiting factors on linux advancing anywhere in the desktop world.

Nope, users are.

Linux people (the ones using it for a long time, not the newbies) are usually the guys you find looking at a CLI. Those people use cdrecord instead of a gCDFuckenBurner, vim/emacs instead of kDevelop, and so on...

I like to consider myself one of those people, and I would dare to say:

EYE-CANDY BELONGS TO MOUSE ENGINEERS, WE DONT NEED THAT CRAP!

So, if mouse engineers are the ones needing it, they must be the ones coding it. Which basicaly means it'll take a lot of time.

Re:Eeek...

[master_p]

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

Language wars are silly, but you are mistaken. The problem with C++ is the lack of good toolkits. Use Qt and will remember me: it's better than Java; and it proves why C++ can be a good language.

Re:Eeek...

[abigor]

Hey, Prolog is awesome! I loved the Prolog course I took back in school...

Then again, writing a graphical app in it would be hell on earth, I'm sure.

Re:Eeek...

[groomed]

Nail Nail Nail Nail

Nail Nail Nail

Nail Nail <b>Hammer</b> Nail Nail

Nail Nail Nail

Nail Nail Nail Nail

Re:Eeek...

[gnugrep]

I've coded in many different languages C, C++, Java, C#, to name a few. C++ is still my favorite for a number of reasons:

1) It allows you to write at different levels of abstraction. You can write a function that is pure assembly code. You can write C style functions or you can use OO techniques like inheritence and polymorphism. C++ is the only language that I know that allows you to use templates, which is a level abstraction higher than the class. Java locks you in to OO, there is no choice.

2) I know exactly what my code is doing. There is no runtime layer that is magically doing something.

3) There are a large number of libraries to chose from, including a garbage collector if I want one.

4) Memory management is not a problem if you use smart pointers. This is the big benefit that Java/C# advocates always point to. I very rarely have to call delete, the smart pointer dtor does the work, but for the rare cases where I need it, I can manage my own memory. Again, it's a matter of choice, I can let the compiler do the work when I want or manage the resources by myself.

5) Automatic management of resources OTHER than memory. Since Java and C# do not have destructors, there is no way to let the compiler clean up other types of resources. For example the std::fstream destructor in C++ closes the file when the variable goes out of scope. I also use classes for entering and leaving a critical section, etc. This is critical flaw in Java/C# in my opinion, since they have exceptions.

6) The latest OS features are immediately available. I don't have to wait for some new library wrapper to use them.

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?

Re:Community standards...

[Anonymous Coward]

I'd still rather that than: "You can't use clue. It allows Evil Software Piracy, and Microsoft is against that. Once you have Clue, you might start to question the wisdom of Corporate control of Government or something Terrorist Like That. We'll Tell You Where You Want To Go Today" - Microsoft.

Re:Community standards...

[Chalybeous]

Thank you, Mr. Data... now would someone please explain that to me in English? :-P
* reads man lart while he waits for someone to hit him with a cluestick*

Re:Community standards...

[mysticgoat]

Alternately, do a low level reformat of hdc, install WindowsME, then download the very small and simple clue.bat from MSN.

This won't enable /dev/mnt/clue but it will provide you with a monopoly approved alternative. While clue.bat isn't as powerful as the /dev/mnt/clue approach, it is available for use to anyone, irrespective of whether they know anything at all.

Re:Community standards...

[Brando_Calrisean]

If you still can't mount /dev/clue after all that, don't forget to 'echo 1 > /proc/clue/fs0/cx002/cluestick/enable'

Re:Community standards...

[Anonymous Coward]

I'm confused. My brain is full. May I be excused, so I can go to the restroom?

Re:Community standards...

[Coryoth]

That's the price of being on the cutting edge of course. More patient individuals can wait for the clue patch to be merged into the kernel, and their distribution to release a nice binary of that kernel version. My understanding is that both RedHat and SuSE are working on this, but Lindows and Xandros will not be including the clue module in their future kernel packages, claiming their users can't deal with such complicated features. There is still much debate as to whether Mandrake should include it or not. On the other hand Gentoo and Slackware have similarly already decided not to include the clue patched kernel in their standard release, under the presumption that all their users already have it installed. Finally, the clue patch is anticipated to be available in Debian Stable some time in the next 4 years. It is already available in Debian Unstable but has been known to crash some (read "all") systems that have installed it.

Hope this helps.

Jedidiah.

Re:Community standards...

[kvakke]

ahem, you don't need make modules in 2.6.x it's only make modules_install.

Re:Community standards...

[WWWWolf]

If not, you might have to create a /etc/clue.conf for your system

Creating /etc/clue.conf doesn't do much unless you have user-space tools installed. (You can, of course, mess with the settings through /proc if you're really desperate.) Don't forget to install clue-tools. (Be sure to get at least 1.4 if you're using 2.6 kernels.)

Oh, and in Debian you don't need to even load the module in boot. Install clue-tools, the new kernel and clue-module (built automagically with make-kpkg if you do make-kpkg modules_image with clue-kernel-source installed - by the way, it's not a patch anymore, it's a stand-alone module, and has been that way for months now!), and the init scripts will automatically modprobe the module if needed. You can still stick it in /etc/modules though.

Re:Community standards...

[maxwell demon]

Of hdc? How am I supposed to low-level-format my CD-ROM drive?

Re:Community standards...

[mysticgoat]

Life without typos would be much less interesting...

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:

[Anonymous Coward]

It may be faster, I can't say for sure, but at least KDE/Gnome don't lock up on a daily basis like XP does.

One would think that dual Xeons and 4GB memory would be enough for XP, but I guess not. :(

Re:I have to say it:

[Anonymous Coward]

If you are locking up your hardware in XP, especially that regularly, I suggest you look at your hardware... namely whether that $20 power supply is sufficient.

Re:I have to say it:

[Anonymous Coward]

It may be faster, I can't say for sure, but at least KDE/Gnome don't lock up on a daily basis like XP does

Why can't you say for sure? Is it because you've never used XP? That would fit with your ridiculous assertion that XP locks up on a daily basis.

Re:I have to say it:

[Anonymous Coward]

On my modern PC, both KDE and XP seem to run at the same speed, even if one is less efficient than the other, because the CPU is so damn fast anyway, I can't tell either way. Now, I know some windows people who try linux for the first time fail to install good graphics drivers, but if you were to run windows in it's "fallback" mode without card drivers, again, you find that it's as slow as Linux + X-Window in "VGA framebuffer" mode i.e. without the correct drivers.

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

Re:I have to say it:

[Umrick]

Not a flame, but given any reasonably supported card (X hardware acceleration) I find XP to be slower than KDE on the same hardware. Even when ratcheting up the geewiz effects of KDE. I can't speak to Gnome as I prefer KDE, so stick to using that.

Right now I'm working on a 2600+ AthlonXP box. It has a SIS VGA controller onboard and yes, XP or 2000 is faster on it by far. Yet on the box next door, it has a low end Nvidia, and KDE is faster than XP on that box.

Now whether all the features are needed, yep, that's preference. I personally find it makes me more productive.

Re:I have to say it:

[Moraelin]

I can relate to your pain, somewhat, but you don't really need to go all minimal to have a snappy and usable system.

E.g., check out XFce 4. If you spend some minimal time configuring it right (e.g., setting the margins so that maximized windows don't overlap the panel, maybe also moving the panel to the right or left edges), it does everything I ever wanted from a window manager, it has themes, it can set the fonts/colours/whatever in GTK and KDE apps... and it starts up in less than half a second.

E.g., for a long time my favourite combo was ICEwm and DFM. ICEwm gives you a window manager, task bar, and start menu, like on Windows. DFM manages your desktop (so for example you can have icons on your desktop like on Windows), and gives you a decent file manager too.

Between the two of them, they use up a mere couple of megabytes of memory and keep X startup time under half a second. And, dunno, they do what my Windows desktop does. (Minus Microsoft's HTML crap which I don't want in Windows either.) I wouldn't really call that "minimalist".

Re:I have to say it:

[Anonymous Coward]

I can't say for sure if it is in fact actually faster, since I've not done any benchmarks to come to a conclusion one way or the other.

My "ridiculous assertion" comes from the fact that I see it happen with my own eyes each day. Once in a while I'm spared for a day or two, but for the most part, it grinds to a halt daily. I suppose I should just be happy that it's consistent right?

Re:I have to say it:

[Quattro Vezina]

If having things run slightly slower is the price I have to pay for having a mature, feature-rich environment, then so be it.

I'll not use a barebones desktop and sacrifice so many useful features just to save a couple of seconds of load time here and there.

Besides, having a feature-rich desktop saves me far more time than slightly decreased load/response speed costs me. I'm a KDE 3.2 user and bloody proud of it.

Re:I have to say it:

[gr8_phk]

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

Joe needs the following:
1) A web browser icon
2) an email icon
3) a new document (open office) icon
4) a file browser (my docs?) icon
5) an icon for any other specific apps he want(GAim).
5) a menu not full of crap

Joe user isn't different from you. He IS you and ME. I write (embedded) software for a living and the only "desktop integration" I really care about is having the correct application open a file I double click on - something windows is actually rather BAD at.

Linux would be ready for the average joe's desktop if someone would just pull all the extras out. Even Knoppix (which I like) tries to pile in a lot of stuff that most people don't want. Where is a distro that has just the subset that everyone wants?

Re:I have to say it:

[orim]

And let me also guess: your grandpa smoked all his life, and he lived to be 150?

Just because it's happening to you, doesn't make it a rule. If your XP is locking up, it's gotta be your hardware. Just ask around, do an *unbiased* survey, and see how many XP users have 0 problems of that nature.

Re:I have to say it:

[AxelBoldt]

Well, at the very least we have established that Linux is able to tolerate his hardware brokenness, should it exist, while XP is not.

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

[flakac]

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

.NET is not a languague, but a platform. This would be the same is me saying, "As a C# programmer, maybe im bias but i really hope that J2EE doesnt become the de-facto language on the windows client." Sounds silly, doesn't it?

Re:Please not .net..

[Anonymous Coward]

You are forgetting the fact that with IKVM, you can still code with Java on the .NET platform.

Benchmarks would be interesting though :)

Re:Please not .net..

[Hard_Code]

Hi there. I'm a Java developer too. CLR is not evil. It is actually nice. From what I can tell, it integrates a lot better with native code that Java, which makes it an ideal candidate. Java's native integration is rather damn weak, as well as it's lack of a consistent flexible UI layer (AWT? Swing? nobody is going to implement GTK or QT on that). CLR will not eat your baby, calm down. It may eat your lunch though. On the server side we are pretty safe however, as we actually DON'T want native integration, for security and portability concerns.

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

[bellings]

With Microsoft's J#, you can code in Java on the .NET platform also.

Standardizing on one set of libraries and one virtual machine would be very, very useful for a standard linux desktop, though. I couldn't care less about the language people use to target that VM and library, though. Java, C#, Python, Lisp, or FORTH -- it's all the same to me.

Re:Please not .net..

[ultrabot]

Developing software for Linux with .NET does NOT necessarily make Microsoft a winner. If it does, where's your reasoning?

At some point, if/when C# has a large mindshare among Linux programmers, and there is lots of C# code around (I hope this never happens), MSFT decides to shut down all the .NET/C# stuff done in Linux. The development is naturally switched over to windows.

They win, we lose.

Re:Please not .net..

[D-Cypell]

You are, of course, 100% correct. I stand corrected.

Re:Please not .net..

[krumms]

Most of the useful stuff (i.e. not Windows Forms, not SqlClient afaik) has been standardized via the ECMA.

The Windows Forms port should never have started. Simple as that. It's dangerous legally, its usefulness is questionable. Personally, I like it when developing for Windows, but for Linux it's just a hack.

If there's any part of .NET that is critical to .NET on Linux which is not in the ECMA standard, somebody for the love of god enlighten me and the Mono/PNET developers.

Re:Please not .net..

[D-Cypell]

It puts Microsoft in the driving seat. They will dictate the advancement of the language and 'standards' and in an effort to keep development portable between the two platforms the developers working on the CLR for linux with work through the night to support the new features.

Do you think this would happen the other way around ?

I would love to see the linux community develop their own language specification for a C#-like language and implement both the windows and linux implementation... take control back.

Its not like Microsoft would have a case, after all, they did exactly this with Java.

Re:Please not .net..

[7-Vodka]

quote:"Bah. Programming languages are programming languages, irrespective of who came up with them."

Yeah... Tell that to your employees and coworkers after M$ pulls out it's patents on .NET and puts you all out of a job.

Re:Please not .net..

[D-Cypell]

With Microsoft's J#, you can code in Java on the .NET platform also.

Only if you are prepared to use 5 year old API classes.

Re:Please not .net..

[turgid]

If there's any part of .NET that is critical to .NET on Linux which is not in the ECMA standard, somebody for the love of god enlighten me and the Mono/PNET developers.

What's the point? Why should any of us waste our time? Some of us have known Microsoft long enough to have become bitter, twisted and cynical. Microsoft has done nothing but bully, lie, cheat and steal historically. Maybe they have changed now and it'll all be different. Who cares? It's too late. We've moved on. Did you ever hear the story of the little boy who cried wolf?

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.

Re:Please not .net..

[bellings]

This is true -- much of the Microsoft .NET libraries started life in 1998 or 1999. If you use .NET from Java, C#, J#, or anything else, you're going to get four or five year old libraries.

But, that's not that awful. It's clear that Microsoft spent an immense amount of time and effort to get the libraries working well.

Or, were you talking about the Java 1.1.5 compatible libraries from J++? Yeah, those suck. I wouldn't use those from J# unless I really had to.

What was the point again? I got confused.

Re:Please not .net..

[Trejkaz]

Technically you can't develop software for Linux with .NET... unless you're talking about developing on Windows with .NET and then copying the resulting stuff to Linux to run on Mono.

.NET is not a programming language, it's a runtime and the associated (Microsoft) class libraries which can be used with C#, Managed C++, VB.NET, J#, and whatever else anyone wants to write a compiler for.

Mono might clone every single class library, duplicating the functionality precisely, but it will still be called Mono.

Re:Please not .net..

[Anonymous Coward]

You can't develop software for Linux with .NET?

Re:Please not .net..

[amoe]

The language/class library itself is Microsoft all the way through. Look at some C# code and weep.

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

[Anonymous Coward]

By that definition GTK is basically MFC by opensource.

Clueless zealot.

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

[zhiwenchong]

Agreed, I think visual IDEs are very important, not necessarily just for the novice programmer, but for the expert programmer who doesn't want to spend so much time to piece together a halfway usable interface. Sure, the back-end code is very important, but if you're writing a desktop app, defining the UI can be a non-negligible activity. Also, stuff like refactoring, code completion, a visible event-handling model, etc. can only help.

I'm surprised no one mentioned this, but I've found that the single most important contributor to productivity is third-party visual/non-visual components - which incidentally is also the strength of tools like Visual Studio and Delphi. It allows you to leverage someone else's expertise very easily. For instance, if I needed a specialized widget (e.g. a cross between a tree and an arraybox), I could just look for the right component, drop it in, set a few properties, and write the code to populate it or whatever. Or if I needed an RTF textbox, or HTML WYSIWYG editor in my program, I'd just drop the component in and immediately be able to see how it looks like. (I sure don't want to write stuff like that myself. BTW, I wonder if how easy it is to drop a Gecko-based browser window into a KDE app and have it work without having to fiddle too much...)

At this point, I'm sure someone's going to mention Eclispse. Well, I've had a look at Eclipse, and it's a very nicely done IDE, but I don't know if it has the equivalent of visual components. (Disclaimer: I don't know much about Java)

BTW, not everyone who needs to write software are full time programmers. Some of us are engineers who write software to solve problems in non-CS domains (i.e. thermodynamics packages etc.). These software often need to interact with the user. For people like us, any tool that helps us achieve what we want, with the least amount of pain, is good.

Re:Visual development environment

[S.O.B.]

At this point, I'm sure someone's going to mention Eclispse. Well, I've had a look at Eclipse, and it's a very nicely done IDE, but I don't know if it has the equivalent of visual components. (Disclaimer: I don't know much about Java)

You might want to check out the Visual Editor Project for Eclipse. Even though it's only at 0.5 it's already pretty usable. They have an online interactive tutorial that shows off the features of the tool by walking you through creating a simple GUI. You can even watch the code being written in sort of real time as you drop components onto the editor. And it's open source.

Re:Visual development environment

[justins]

Glade isn't a "development environment", it's an interface designer. Linux doesn't really have development environments as someone used to using Visual Studio would understand them, with Kylix being the one possible exception.

Re:Visual development environment

[Joe Tie.]

Linux doesn't really have development environments as someone used to using Visual Studio would understand them, with Kylix being the one possible exception.

Off the top of my head, I can also think of Boa. It has the usual IDE code editing, as well as a form designer and drag n' drop code components.

Re:Visual development environment

[mortenmo]

I agree, java is fast enough, even swing, but I like native widgets with native themes on applications.

There already is an alternative to Swing which does use native widgets, and doesn't tie into a particular widget library, namely SWT from Eclipse. It can be used in standalone applications as well as within the "Eclipse platform".

SWT already has bindings for GTK/Linux, Motif on various platforms and Win32, so applications can be written to use native widgets on a various number of platforms. Hopefully there will even be QT bindings in the future (I'm a KDE user myself :)).

http://dev.eclipse.org/viewcvs/index.cgi/~checko ut ~/platform-swt-home/main.html

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.

Re:Visual development environment

[justins]

Linux doesn't really have development environments as someone used to using Visual Studio would understand them, with Kylix being the one possible exception.

Off the top of my head, I can also think of Boa. It has the usual IDE code editing, as well as a form designer and drag n' drop code components.

If you're talking about Boa Constructor, I've tried that and it certainly doesn't qualify in terms of features or usability. That's not the end of the world, either, since not everybody wants or needs the feature set of Visual Studio, particularly if they will be using gcc with automake and friends. It's just that there's a whole set of expectations Visual Studio users have when they try this stuff, and it's pretty consistently not met.

As for me, I really wanted to like Boa Constructor. I haven't entirely given up on it yet, but the interface just seems pretty horrible to me. To continue the comparison, it's much less powerful than Visual Studio, but the interface throws even more iconic UI horror in your face right off the bat. Maybe I just need a decent tutorial.

I like kylix but it's got its own set of problems. Alas for the Borland I grew up with.

My favorite cross-platform RAD-type IDE today is Visual Tcl. It's vastly less capable than something like Visual Studio but it's got a simple interface that I really like - the simplicity of the interface seems commensurate with what the thing actually does. Tomorrow it might be something different. :)

Re:Visual development environment

[Anonymous Coward]

But Gtk basically is MFC by open source.
If you want a real toolkit, use Qt!

Re:Visual development environment

[Trejkaz]

I like Swing personally. But that is to say, "hey, at least it isn't SWT." From what I've seen of Qt/Java and similar native bindings, they are almost certainly better, but having something tied more to the language would be great.

I was hoping when they developed something like Swing, that they would have taken the rather decent framework already provided by AWT, and simply extend it. And not in the way they did. I mean making native tree components like SWT has, just without SWT's crappy API.

As for automation... yeah. I guess we should all be using functional programming languages, which even automate the order in which things are executed so you only need to write the logic. That would be schweet. :-)

Re:Visual development environment

[JanneM]

You have Anjuta (anjuta.sourceforge.net).

Re:Visual development environment

[justins]

You have Anjuta (anjuta.sourceforge.net).

No I don't. Perhaps you do. In which case, you also have my condolences.

Re:Visual development environment

[IntergalacticWalrus]

Java - the programming language - has always been fast

uh... NO.

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.

Re:Hey, wait a minute....

[Deusy]

How is the parent 'informative'? Are people who moderate even bothering to compare the articles?

The other story is about the release of Gtk2.4 and associated libs, which is an event in itself.

This story is about the future of the Gnome desktop (or indeed Free Software desktop in general) by assessing how a framework can be established that is a direct (and hopefully superior) alternative to the framework Microsoft will be introducing with Longhorn.

Re:Hey, wait a minute....

[Asprin]

Aw, crap. You are right on, brother. /. needs an 'unpost' button.

Mods, please down-mod grandparent into obscurity.

[slaps own hand] BAD ME! [more repeated self-slappings]

[Author's note: My original comment was based on misreading the first line of the article. I thought it said *GTK* was due in a week, leading me to reference yesterday's article about the GTK release. heh, heh.... giggle....]

[Another author's note: If I am not willing to read the articles before commenting, why should the mods be bothered to read the articles before modding? I know, we're losing it....]

And now, the rest of the story

[Anonymous Coward]

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

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

Regards,

A. C.

Re:And now, the rest of the story

[Anonymous Coward]

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

Note that the size of the latest Pyramid was ever increasing

Re:And now, the rest of the story

[thelasttemptation]

"They" want this waste/consumption of resources to force people to buy the Next Big Thing.

And this helps open source how?

Re:And now, the rest of the story

[gnuman99]

This isn't American and it isn't even Capitalist; it's Human

No, it is the purpose of Life. The purpose of Life in the universe is to increase entropy. Don't know why, but that is the common denominator for everything, including evolution

Re:And now, the rest of the story

[handslikesnakes]

result != purpose

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

[lofoforabr]

Am I really being a troll just because I said something true? Try to run java based things on a i486 to see how painful it is.
Java and C#, though it has all its wonders, are not the way to go. They are portable, but so is C/C++ to an extent. It just isn't the way to go.

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

[Decameron81]

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

It mostly depends on what respectable means to you. I seriously don't want to end up buying a computer 10 years in the future from now that runs programs as fast as the PC I am using right now. I think there is a certain degree of speed loss you can accept in exchange of a better development environment, which depends highly on the kind of application you are coding. But I refuse to accept the main principle of Java, which is to make computers compatible by running all code with an emulator (of a virtual computer). Especially when the compatibility it claims to have is not respected by all systems.

Don't get me wrong, I don't want to get Java lovers angry here. I realize that my opinion is no more than that, an opinion. But think about it: wouldn't you prefer libraries that allow easy transitions from a Windows C code to the equivalent Mac C code? or to Linux C code?

I know many people finds java to be great because they don't need to compile their code and test it for several systems. But if they could do the same thing with lower-level languages like C... wouldn't they find that much better?

Diego Rey

Re:High level languages

[mydigitalself]

i'm sorry but i don't buy this performance thing as much as you (and others) sell it.

i've got two old boxen at home. one is a 500-odd MHZ Celeron which runs Linux and serves as my router/firewall/mail/apache (the usual basically). i know the kits old, but the performance i get out of it isn't that impressive.

but wait... i'll actually COMPARE something now!

i've also got an oldish 700 odd MHZ Pentium III (i think). this is my desktop box. i've always been a linux on server, winblows on desktop purely because of historical work purposes (Photoshop, VS.Net etc...). so that box used to run 2k, and then XP for a while. then i discovered both VMWare and CrossOver which allow me to run anything I want to. so i trashed my windows parition completely and installed RH 9 on it...

believe me, there is hardly any noticable performance difference between the two - and i'm not talking about running Photoshop in CrossOver or VS.NET in VMware - those are bound to be slower. i'm just talking normal X stuff. moving windows around the screen, finding files, launching small apps etc... there is no obviously noticeable performance differences between the two.

and with regards to your JAVA comments, yes I actually have. SWING/AWT USED to be pretty slow. since 1.3 and especially in 1.4 the "snappyness" of the UI interfaces have improved dramatically. go get a 1.4 JRE/JDK and run IntelliJ (http://www.jetbrains.com/idea/) and you will discover that it runs just as quickly as any native linux IDE - and by IDE i'm not talking frikking vi here...

Re:High level languages

[Tim C]

Yes, I have, I'm using one right now (or at least, I should be ;-) ). JBuilder is plenty fast enough for me. No, I'm not trying to run it on an old P2 with 128meg of RAM, but that's not the sort of machine that people buy. Hell, 15 months ago I bought what I considered to be a bog-standard machine - P4 2.6Ghz with 512meg of RAM.

Maybe my expectations have been set too high (I'm a Java developer and gamer), but frankly, I don't think that's a "super machine". To me, a super machine would be at least 2-way SMP with a gig or two of RAM and large, fast disks.

Re:High level languages

[iapetus]

I think you're working from some misconceptions there. I don't believe even bad Java code with dependencies on slow and nasty code (like Swing) is going to make a computer from 10 years in the future run as slowly as the native equivalent written today.

I'm using a PC that's mildly obsolete by today's standards (PIII 600MHz, 256MB of memory), and I use big graphical Java applications on it all the time without much of a problem: memory is the only real issue, and that's as much a problem with non-Java applications. I'm using Eclipse as my primary development environment, SQuirreL to access the range of different databases I need to talk to from day to day, jEdit as an occasional text editor. And I'm not feeling bogged down by hideous speed loss.

Re:High level languages

[nikster]

>>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 have even written several myself...

how fast? hmm.... fast enough to not annoy me. and i regularly shoot down programs that stall for even a few seconds.
let's put it this way: they are faster than windows Explorer.exe, which i have to kill about once every day. Explorer may not be a brilliant piece of work, but it's certainly as native as they come...

i can bet you a dollar that you can't distinguish them from native c apps, except for startup time and memory use (which are related of course: it takes some time to fill up 25M of memory). but Sun is working on it - memory use is one of the top 25 RFEs.

in terms of speed, Java has come a long way. the slow apps you see today are
1) applets - those are abysmal, and i have Java turned off in all browsers. there is something seriously wrong with them.
2) badly programmed. it is very easy to create functioning apps with Java, so people who have absolutely no clue what they are doing are producing apps. in C++, those would not even run. but in Java, they run, and are slow, and look bad. simple example is the garbage collector: you can leak and leak memory and the java app will just get slower, whereas c++ would crash and burn.

there are several studies that convincingly show that Java with a hotspot compiler is just as efficient as c++ - give and take, but it's faster in some cases, slower in others.

Java has also come a very long way and i would call the GUI performant only since 1.4.x and later. it used to be awfully slow, and ppl still have this perception.

i just wish Sun would give in and make Java open source, fair and square. the potential is enormous.

Re:High level languages

[Anonymous Coward]

Ok - this is my take, and it is really simple.

Create a java based framework with a C/C++ forms/widgit tool kit - like Eclipse does, that way you get speed at the UI level, and java is pretty fast as long is it is not rendering UI componets. The frame work can mock the usiblity of .NET functionalilty without cloning it, Just like Microsoft mocked java with C#, but did not clone it.

Thats it, do that and you will win. Well do that and one more thing - document the FREAKING framework - and I don't mean JavaDocs! It should be as easy as somebody trying to mess around with VB to build something.

The last thing the Open Source world needs is another overly abstract, undocumented, obscure, framework that only kernal developers and sourceForge news group readers know about - in others words - it needs to be promoted, documented , and backed by some big names in conjuction with the open source community.

If you had that, Linux could blow MS out of the water once and for all.

P.S. - I like Mono, but I don't think we need it.

Re:High level languages

[AndyS]

That's a nice benefit of Java - one binary, every platform.

But the REALLY nice bits about Java are
1) Array bounds checking (no stupid screw-ups like trashing random bits of data through bad array accesses)
2) Garbage collection (no more pain trying to figure out where to deallocate objects in long running systems. No more defensive copying of strings, etc)
3) A massive class library with ui stuff, sound, xml, etc, all in a fairly consistent form?
4) Some fantastic IDEs (go visit eclipse.org)

Go play with gcj at some stage - a native code Java compiler. It compiles Java into native code using GCC as a backend.

Now Java isn't perfect - C# seems to have some nice additions (a lot of people like the idea of delegates, which are basically method pointers), but Java has a fair amount of support and has a fairly nice API to use.

Re:High level languages

[GnuVince]

and soon Linux will not run anymore on low end systems, either requiring a super machine (like Windows) or running painfully slow.

What _one_ project does doesn't affect what other projects do. If you have a good machine, you have the option of using GNOME. Otherwise, stick to the command-line or fvwm or whatever is light enough for your setup. You don't whine about Mozilla being written in C++ yet being extremely big and slow. Even if GNOME uses C# (which is not that much slower for their intended uses by the way), the kernel and basic tools will still be written in C, and there will still be lightweight projects for lower-end machines.

We don't need to keep making projects that fit all sizes.

Re:High level languages

[steelem]

So I'm learning that the Java GC is horrible with paging and memory etc. While I know c# uses some native calls to speed things up, what tradeoffs are involved in speeding up the java GC? I have to imagine with all this "common" knowledge about the Java GC, that sun or the JCP must have a great reason (portability or something) for not improving the performance. So what is it? Can it get better?

Re:High level languages

[Anonymous Coward]

Azureus. Eclipse.

Re:High level languages

[Trejkaz]

IntelliJ IDEA. It's faster than any competing application... its built-in editor even responds faster than the (native!) editor in KDevelop.

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

[Anonymous Coward]

If people are avoiding language, it'd be best to avoid C++ too. Common Lisp, baby, yeah.

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.

Re:All anyone needs...

[djeaux]

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

IANAC++P (I am not a C++ programmer), so I'll take you word on that. But I do agree with the virtual machines complaint. The GUI should not be something run on a VM.

I've seen plenty of Java apps that either refused to run at all or caused lock-ups when the installed version of Java was older or newer than the app required. Perhaps they were poorly written apps, I dunno.

Somebody else here posted the observation that the WinXP desktop is faster than Gnome or KDE. How much slower would KDE run under Java or some other VM-based scheme? "Overhead" has a lot to do with speed & VM is overhead.

Go ahead & mod me down for not toeing the party line about Java... <sigh>

Re:All anyone needs...

[turgid]

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

That's all very good if all you want to code in is C++. You see, C++ has a complicated ABI, so it is difficult to interface it to other languages. It is even very difficult to use C++ classes compiled with one compiler with code from another. This is because each vendor implements their own, proprietary C++ ABI. The gcc folks have tried to solve this problem by defining a Multi-Vendor C++ ABI. Unfortunately, gcc is the only C++ compiler that implements it just now. Some of the other vendors have pledged to implement it sometime manyana, but in the mean time, if you want to ensure that code and libraries communicate with each other, you have to stick to the good old unix C ABI.

Re:All anyone needs...

[BiggerIsBetter]

Except that aside from being OO, C++ has most of the pitfalls that make C a bad language for desktop programming. And I like C/C++. That said, I also like Java, and think it's pretty nice for this kind of work. Any speed issues have improved hugely with SWT, and as most folks seem to ignore, it's actually very popular in embedded and small devices. If it's used sensibly, it doesn't have to be big and slow. In fact, it has the potential to be faster with a smart JVM that can optimize effectively.

Re:All anyone needs...

[jasondlee]

Isn't SWT portability-challenged? IIRC, SWT depends heavily on JINI, which makes it a bear to port the library (not the client code) to new platforms. Swing, on the other, is pure Java and has become MUCH faster with recent JVMs. I have used several Java apps on 1.4.x+ JVM and haven't seen any noticeable speed problems. I think any lingering speed issues WRT Java are due (mostly) to poor programming, not the language/JVM. YMMV.

jason

Re:All anyone needs...

[AndyS]

Huh?

Why would KDE be significantly slower? People aren't talking about doing a Swing here and rewriting GTK in a low level language, they're talking about writing the overall logic of the application in higher level languages.

How often have you written a linked list in C, how often have you done a hashmap. Java (and I imagine .NET) has both of these. They can be tuned and optimised. You can rely on garbage collection and array index checking to eliminate stupid mechanical bugs. And when you need speed, you can use C. But 90% of your application will not need to be written in C, and thus can be implemented in a much safer language.

I imagine it would make less difference to KDE or Gnome than you think to write applications in Java or C#

Re:All anyone needs...

[Hard_Code]

Oooh you're disagreeing! How independent and freethinking!

Anyway... Java is a language, and the article talks about adopting the /language/ not the /platform/. GCJ natively compiles Java. Sure there is overhead in a VM. There will be unavoidable "overhead" in adopting some higher level platform, no matter what it is. The game we are playing here is not "how fast I can spin my CPU" it's "how can we not lose relevance in the face of obvious productivity gains by higher level languages/platform".

If Java (VM) /was/ open sourced, I'm sure the very first thing that would happen is that open source developers would implement a pre-emptive JIT just like CLR/Mono has.

Re:All anyone needs...

[molarmass192]

You really need to qualify that with "All *I* need ...". I write Java server apps that get deployed on AIX, HP-UX, Solaris, Linux, and (sigh) Win2K. I have Q/A review the binary set once and the *same* binary set goes out to all our users unchanged. I like C++ a lot but the multi-platform aspect of Java (do not say "distribute the source and let them compile it", it's not my call) is a huge feature.

Re:All anyone needs...

[Anonymous Coward]

C++ doesnt even have the simple abstraction such as PROPERTIES rofl, you have to Hack this in with Templates (not compiled but preprocessor substituted) and or COM like technologies, C++ is not a good object orientated language by any means Its jsut Cludge++.

Go ahead stick to yer C++, we got no work for you, you know, the stuff that puts food on yer plate at the end of the day. We win, you lose.

Re:All anyone needs...

[nickos]

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

I'm not disputing that. I'm currently editing some Java (bleh) in an IDE written in Java (double bleh) on my nice super fast new Dell, and every so often I have to wait a couple of seconds for all of the characters I've typed to appear. GUI code written on languages that use a virtual machines are hugely inefficient. A 2 Ghz PC should be able to run a text editor faster than my old 7 Mhz Amiga 500!

Re:All anyone needs...

[Glock27]

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.

Almost everyone in this discussion seems to be missing the fact that gcj isn't (primarily) a VM. The point of gcj is to traditionally compile Java (or Java bytecode) ahead of time, with full optimizations. This is also a tradeoff, but an acceptable one for many situations.

The reason gcj runtime memory requirements are large is that it uses a garbage collector, and GC requires an initial, non-trivial heap. With the advent of 512 megabyte entry-level desktops I'd suggest that isn't much of a concern either. You can only use one app at a time, if others swap out oh well. ;-)

This will be even less of a concern as the 64-bit desktops take off with > 4 GB address space.

Re:All anyone needs...

[nickos]

"C++ is not a good object orientated language by any means"

C++ supports multiple inheritance, unlike Java.

Re:All anyone needs...

[nickos]

But if we're talking about the Linux desktop and assume that it will continue to be open source, then compiling from source certainly is an option. It may not be an option in a closed-source commercial software house (where I'm presuming you work), but then I guess you're not writing GPL'ed code.

Re:All anyone needs...

[turgid]

The old-timers rave about Smalltalk. I haven't tried it myself...

Re:All anyone needs...

[Anonymous Coward]

How often do you use multiple CLASS inheritance? Its very rare and rightly so, but yes It has its places but I would seriously consider reevaluating your design.

Properties are MUCH more useful then Multiple class inheritance and macros, not to mention custom attributes and now managed generic types (less casting overhead and thus less runtime type checking).

Re:All anyone needs...

[Short Circuit]

Ah, but what if you could run GNOME instead of Explorer as your window manager/desktop environment on a 'Doze box? It would make for a great development platform.

Granted, someone should have tried that with Java a long time ago, just as a proof of concept.

Re:All anyone needs...

[omicronish]

Both C# and Java are compiled to bytecode, which is compiled to machine code at runtime via JIT'er. I haven't seen numbers for myself, but apparently the Java JIT'er can possibly produce faster machine code than plain C/C++ since the compilation process is continually optimized based on program behavior, which, if it isn't true, is still something that seems entirely implementable with both .NET and Java.

Additionally, my primary reason for using C# is because it simplifies various little things in C/C++. I can handle memory management in C/C++, and it isn't conceptually challenging, but it's tedious and hard to do perfectly. Higher level languages eliminate a lot of the tedium.

ATTENTION PEOPLE

[Anonymous Coward]

There never was a problem with the file selector. The file selector is good. Lies were told about it by ungood MS and the hated Billgates
Linux already is the best desktop. Anyone who lies about that spreads MS FUD and is guilty of thoughtcrime
Linux could not be improved, as linux is doubleplus plusgood already
Disliking Linux is a sign of ungood crimethink

Signed, the /. collective hivemind

time to move on

[pumpumpum]

These guys realize that they have to move on, failing to provide a decent desktop. Good luck for the "new, improved" project.

Linux did not revive Unix

[sczimme]

The large open source projects could drive Java deep into Linux, and bring it new life, just as Linux revived UNIX as a whole. (my emphasis)

I disagree with this statement. Unix was doing quite well in the server and workstation market in the mid-1990s when Linux began to make its presence known. (Yes, Linux existed before then; no, it had not made significant inroads as of ~1995. Sorry, fanboys.) Yes, Linux made the Unix-oriented evnvironment available to more people, but piggybacking on a current and widely-used platform != revival.

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.

Re:Commercial Linux Apps

[Anonymous Coward]

You stupid clod.. dreamweaver is being released with wine.. not a native port.

Re:Commercial Linux Apps

[denks]

The battle for the Linux desktop has really been heating up lately

Timed to coincide with the year of Linux on the desktop. Oh wait, that was last year. Oh wait, it was the year before...

and with the planned release of several big commercial apps (Macromedia), it's getting even hotter.

Yep, it will get so hot with Macromedia releasing native Linux apps. Oh wait...theyre not.

I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in .NET

As above

Don't believe the hype dude; the MS marketing machine has been blowing a lot of smoke up a lot of asses.

Nobody uses VS.Net...all MS FUD. All major software houses have secretly decided to stop production of Win software and are going to release all future software for GNU/Linux only. However we here at /. are the only ones who actually know of this secret. Anyone who says otherwise is spreading MS FUD and is guilty of thoughtcrime.

Nothing to see here, move along...

One word... Smalltalk...

[Anonymous Coward]

Have you seen squeak? Imagine if it had just a bit more modern eye-candy!

-- ac at work

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.

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!

[Anonymous Coward]

What about Intercal(insane paradigm)?

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!

[Anonymous Coward]

I don't know about logical programming, but functional programs tend to run an order of magnitude slower than programs written in Java or C#. Forget 3ghz processors, you will need 30ghz. (Granted most time of a program is spent in a few small inner loops, and you could write the inner loops in something faster so in practice the performance decrease won't be that extreme.)

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

Re:These languages are all outdated!

[seguso]

Actually the post passed from an initial "insightful" to "informative" to "interesting" to "funny"! Ouch!

hmmm

[Anonymous Coward]

I was a gnome diehard for a long time. But now they are opening it up to legal issues with this .net copying.

Further, WTF is with object oriented nautilus in 2.6? Can someone explain how having hundreds of windows exploding onto my desktop as I browse is beneficial? And if it's for "ease of use" then can someone tell me how abandoning what the other 2 Major OSs are doing is "easy of use"?

Methinks there is some UseInterface Jihad warriors who could be kept under control. This is ONE thing where you do need an easy to use control panel to change between options.

Gnome is going in the wrong direction IMO.

I opened up KDE 3.2 to find konqueror quite nice actually, their tabbing is comparable to moz/fox now and the interface is cleaner. Sure KDE had "lots of options behind the scenes" but they are still behind the scenes, only one or two more "on the surface" extras to gnome.

There might well be a migration to KDE from Gnome to avoid legal issues if too many apps get developed in mono.

Re:hmmm

[Enahs]

Cute. Someone makes what I see as a valid point about the future of GNOME's interface, and someone mods it as "Flamebait."

I agree wholeheartedly about the new Nautilus system. I'm told it's possible to switch, but a cursory look at the preferences didn't reveal it. This is probably one of those "power user" features that you have to muck around in GConf to change, or something. Or did I just miss something blindingly obvious?

This takes something that I thought was one of the worst things about the old MacOS (double-clicking on a folder in Finder opens a new window) and runs with it. Back before OS X, I used to sit with one hand on the mouse, and one finger on the (forgive me if I say the wrong key, as I use the key without thinking aobut it) Option key so that opening a new folder would close the previous one. Only rarely did I want default behavior.

The new Nautilus default behavior is a major step backward, IMHO. Then again, so are many of the usability changes. Is it really better to relegate extra features to GConf hell?

Re:hmmm

[Zapdos]

There is no copying. This is all original code and even if the Windows API emulation layer goes away, there will still be plenty of gpl layers left.

Gnome is simply going to the next logical level.

Re:hmmm

[Lussarn]

If I'm not mistaken you rightclick on a folder and choose browse to get to the old behaviour. I'm not in front of a 2.5 at the moment though.

Re:hmmm

[zhenlin]

A rant about the state of the current OS X Finder, and its non-intuitivity for spatially-oriented persons (i.e. most everybody who lives in meatspace).
The spatial finder.
But, once you get used to it, I think that the current single-window-change-current-window model is acceptable. But it can be highly confusing to people who are spatially oriented. Such people prefer files/icons in the computer to act like objects in the real world: stay where they last put them (assuming no one else moves them).

Re:hmmm

[Jason Hood]

Well said, This is a prime example of open source project where the members (or leaders) are running around the playground with their eyes closed trying to use the Force. No offense to them, but they need to start getting more input from QA minded people. I think this would greatly improve the direction of gnome.

I expect this "feature" to be disabled by default in a future release as it is impractical for everyday users. Whether you are surfing a source tree, browsing your music collection or a searching a photo collection, this navigational schema just does not suit. Yeah I know you can change it. You can also turn AA on and off. Where do you do this? A config file for both. So much for HIG.

-Yeah I am not "slashdot mainstream" so mark me as a troll please.

Re:hmmm

[superjaded]

As of GNOME 2.6beta1 (and probably before) there are about three ways to get the non-spatial Nautilus

1) as another poster said, right click->Browse Folder
2) The only filemanager button in the Application menu is "Browse Filesystem," which opens it in the browser interface
3) To make it default to the browser mode, open gconf-editor and go to apps->nautilus->preferences->always_use_browser

It would be nice, I guess, if they, eventually, made a visible preference in a dialog box for defaulting to the browser mode, but once you get used to the new interface, it's A LOT more useful than browser mode for actual file *management,* IMO.

There are ways to limit the clutter traversing through directories though -- like ctrl+L for inputting a path name directory or double middle clicking to close the parent window when the child directory is opened.

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

[Anonymous Coward]

I think it's really sad that people think Java/C# are good... based on them being better than C++. Better than C++ is NOT GOOD, it's just slightly less sucky. Use Common Lisp, as another poster suggested. Use Python. Use Erlang. Use ML. But for pity's sake, realise that Java/C# only look good COMPARED TO C++. Compared to real languages, they are ABYSMAL.

Re:Language Evolution

[alext]

Really? I would be interested in your perception of the relative investment in Java-on-Linux vs. C Sharp-on-Linux, because my impression from inside corporates is that Java is the main driver for adopting Linux in the organization whereas C Sharp / Mono is nowhere, and I mean nowhere.

The prospect of C Sharp / Mono winning from this position is remote to say the least.

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.

Re:Language Evolution

[nonmaskable]

Java is the main driver for adopting Linux in the organization

Not my organization. Java is part of the picture, but nothing more. IMHO, the corporate driver is the width and depth of development and infrastructure tools - Linux as the swiss army knife/melting pot of environments.

The prospect of C Sharp / Mono winning from this position is remote to say the least.

For server side stuff I agree...for now. Let's see once/if client side uptake explodes.

For client side stuff (and that is the subject of the article) the exact opposite is true IMHO - Java had years to get it together, and has failed. One last chance would be to throw in with IBM/Eclipse/SWT. As long as Sun isn't in that boat (and dealing with the free/open issue is the admission price), Linux .Net will have a huge opening.

Re:Language Evolution

[Anonymous Coward]

This will, of course, get much easier when all of those high-level langauges can talk to eachother through Parrot as a back-end.

"When"?

You can say that when Parrot's anything more than vaporware. Till then, please use the more accurate qualifier "if by some miracle it ever becomes the case that".

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.

Re:Never in Mono

[Anonymous Coward]

Java is proprietry. Enjoy your lockin.

Btw, have fun using CUSTOM Attributes.

Re:Never in Mono

[lupus-slash]

Note that we still need to do some performance and memory usage optimizations for Gtk# apps: we have just focused on implementing until now. I expect
the memory usage to drop significantly in the next few months as we approach a formal release.

Re:Never in Mono

[gabebear]

why exactly is Mono doomed but Java good?

The legalality of Mono needs to be established before I'll touch it. I doubt this issue will be put to bed anytime soon, I would say it warrants a "doomed" label in my book.

Implementions of the .Net API isn't guaranteed to be free, only RAND "Reasonable and non-discriminatory", Microsoft can charge people for implementing it.

check out this thread in "C is dead"

Can someone point to where Microsoft has said that .NET/C# and all associated patents are royalty-free?(message boards don't count) I'm not going to trust Microsoft not to start charging a non-discriminatory fee for implementing .NET, as it seems they have the right to.

I'm not sure if Java has these same problems, but it doesn't matter(as much) because you can get SUN's JVM for Linux w/ source, it's not GPL compatible, but frankly, I don't care. Java is legally available for almost every platform.

Re:Never in Mono

[FattMattP]

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?

Maybe because Microsoft is a twice convicted abuser of their monopoly position and frequently use either legally questionable or outright illegal methods to harm their competitors? Sun looks like a saint next to Microsoft.

Re:Never in Mono

[Anonymous Coward]

Go check out Groklaw. If MS begins using its patent portfolio to harrass open source uptake in the marketplace, Mono will likely be a prime target.

Re:Never in Mono

[Anonymous Coward]

I find Java too anal for my tastes

Bad coffee always tastes like ass!

Re:Never in Mono

[jas79]

Maybe because Microsoft is a twice convicted abuser of their monopoly position and frequently use either legally questionable or outright illegal methods to harm their competitors? Sun looks like a saint next to Microsoft.

You need to have a monopoly position before you can absuse abuse it. And I see no reason to give Sun a monopoly to see how they handle it.

Re:Never in Mono

[hitchhacker]

Can someone point to where Microsoft has said that .NET/C# and all associated patents are royalty-free?

Jim Miller of Microsoft on the .NET patents
quote:
"But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went further and have agreed that our patents essential to implementing C# and CLI will be available on a "royalty-free and otherwise RAND" basis for this purpose."

uhh.. can I get that in writing, Jim?
I don't know about ya'll, but I'm sure as hell
not going to trust Microsoft. Especially when
they become backed into a corner by gnu/linux.

I think we need to mirror any apps developed with mono. Mirrored in a "safe" language.

see Mono's FAQ#131 from the horses mouth.
They must be _insane_ to trust Microsoft.

-metric

Re:Never in Mono

[Anonymous Coward]

At the moment I'm hoping Parrot succeeds and that every weakly typed language gets rewritten to run in it. Then instead of .NET's current strategy of mixing languages which all sucked, we can mix languages which don't suck.

Re:Never in Mono

[gabebear]

reimplementing all programs in C++ after you write it in C# is silly.

I started thinking about it, and what does "royalty-free and otherwise RAND" even mean?

It's that "otherwise" that could make this mean "We made some stuff royalty-free, but we used the RAND terms for the rest of it. Aren't we great for giving some of it away, we will be billing you shortly."

Just some healthy paranoia, you have to admit the wording is strange.

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

[Anonymous Coward]

A minor nitpick:

// C++
typedef list StringCollection;
StringCollection strings;

StringCollection::iterator itr = strings.begin();
for(; itr != strings.end(); itr++)
cout << *itr << endl;

Not too hard, eh?

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

[zhenlin]

Which is easier:

* Porting one small app

Or

* Porting one huge library and app

Obviously, porting the small app is easier. However, in the big picture:

* Porting millions of small/medium/large apps

or

* Porting one huge library and app

and you see the benefits. However... in the case of JRE+JVM and .net+CLR, neither have been ported to very many platforms.

Of course, this argument completely ignores the differences in featureset between non-Oakian (a new term I am coining for Java-like programming languages (not Java-like runtime libraries)) and Oakian programming languages.

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

[PhrostyMcByte]

Porting one huge library and app

Not true. I don't know about Java, but Mono's class library is written entirely in C#. The only thing they worry about porting is the JIT.

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

[Anonymous Coward]

C++ doesnt even have the abstraction of properties or attributes, go figure.

Its Cludge++ of macros and other hard to debug "features".

As for multilanguage features, rofl, more Cludges in the form of _T macros etc, what else hmm, no language independant way of packaging objects, except we have to bolt on COM. What else, all that code duplication between definitions and imeplementations. Im sure I can think of more cludges in C++.

At the end of the way, we hold the money, we are the ones putting food on your plate so you use what toosl we the designers choose and right now we are using C# and C++ managed extensions but this is only on a as few places as possible due to the inherant problems of C++.

Yeah and the compiler, well theyre not smart at all, i mean I have to code someconstantvalhere == variablevalue becuase the compiler cant check the == properely. More C++ issues.

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

[JimDabell]

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.

They're called coding standards. If a certain project has no use for certain language features, and there is a downside to using them, then they shouldn't be used in the first place. One of C++'s design constraints was that you shouldn't have to pay a penalty for language features that you don't use. This applies here directly.

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

Absolutely. But the downsides are that they are different languages, have different libraries, and not as many developers know them. The downside to not using pointer arithmetic, for example, is simply that a developer could go against the coding standards for that project, use the features, and screw up. The fix in that case is to give the developer a hard time for ignoring the coding standards, not to throw away the language, libraries and massive amounts of developer experience in using that language and those libraries.

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

[zhenlin]

The Java class library is written mostly in Java.

But I'm sure both Mono and the Java class library have non-native portions. Especially where interfacing with GUIs is concerned. And that's not the only thing. Other low-level-ish things need to be ported, like networking, remote invocation etc.

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

[top_down]

Or with the boost lambda library:

#include <boost/lambda/lambda.hpp>

vector< string > v;
...
for_each(v.begin(), v.end(), cout << _1 << "\n");

Not too hard either eh?

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

[Anonymous Coward]

Cool. I haven't used Boost all too much. It seems too large or something, I can't tell what's what and some of the API's are of questionable quality (Regex for example).

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

[happyfrogcow]

yeah, maybe people don't. And maybe these same people never realized that you can use a third party garbage collector in C++, if that is what you want to do. Maybe these people don't know about C++ STL, or how to use constructors and destructors in a way that can eliminate much of the resource management problems that C-like C++ code has.

language wars... what a fun subject to follow :) Freakin' Java can bite me. Java.is.way.to.verbose in code style for my liking.

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

[Anonymous Coward]

// C++
list&lt;string&gt; strings;

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

Without boost (someone already posted one using lambda, which is quite nice), and I don't like using:

struct FPrintLine
{
void operator()(const std::string &item)
{ std::cout << item << '\n'; }
};

FPrintLine fPrintIt;
std::list<std::string> strings;
std::for_each(strings.begin(), strings.end(), fPrintIt);

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.

"Console.WriteLine" is a cheap shot. It's only more intuitive than the C++ equivalent because it's hard coded in english for this special case. Is there "WriteAsTabSeparatedValues"? How about "WriteDateInLocalizedFormat"?

Try the equivalent of:

struct FPrintLine
{
unsigned line_;
FPrintLine() : line_(0) { }
void operator()(const std::string &item)
{ std::cout << ++line_ << ": (" << item << ")\n"; }
};

FPrintLine fPrintIt;
std::list<std::string> strings;
std::for_each(strings.begin(), strings.end(), fPrintIt);

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

[top_down]

Yes, the boost::regex library is much too complicated for my taste too. Another one I don't like is the boost::thread library.

But Boost nowadays consists of about 30 libraries or so, many of them header only. The graph library, the spirit parser generator, the smartpointer stuff, boost::bind, that's all pure gold.

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

[Hard_Code]

Ok, so:

* pick a third party garbage collector, or equivalent. There is the Boehm one, and of course lots of people like to use various flavors of the smart pointers that the Boost lib provides. hope that all other projects choose the same one, or learn each one that others pick
* use a collections/template library of your choise. hope that all other projects choose the same one, or learn each on that others pick

etc.

You're right in that there are choices. If there were "standard" libraries for all this since day one the problem wouldn't be so large.

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

[top_down]

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.

Yes, a JIT can at least in theory produce more efficient code because it has extra information: it _knows_ on which processor it runs which is a luxury the C++ compiler might not have.

However, C++ uses the same trick (i.e. postponing code generation) a level higher: C++ libraries are often distributed to Application programmers in the form of templates instead of code. So the application programmer generates the binary code and at that point the information on what the container will contain or on what the algoritm will operate is available. This results in much faster code (easily several factors under the right conditions). Just benchmark the STL sort() against the C, Java or C# equivalents to verify this.

It will be interesting to see if Java and C# generics will be able to close this gap somewhat.

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

[Brandybuck]

The problem with C++ is that it has too much power and flexibility, much of which it inherited from C.

The problem with Linux is that it has too much power and flexibility, much of which it copied from Unix.

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!!! ;)

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

[prockcore]

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.

Yeah, that's one thing I really like about mono.. the standard class library is amazingly complete. Too many C++ libraries are really just poorly ported C libraries.

Plus every C++ library my program needs, is another dependency.

I'm working on a program that needs to talk to a web server and download an AES encrypted gzipped xml file and parse it. That's 3 dependencies that my C++ requires (crypto++, libz, libxml2) and I had to write my own network class to do the web request. Plus two of the dependencies (libz, libxml2) are C libraries.

While the standard class library in mono provides fully object oriented classes for everything.

C++ may have the speed, but it cannot compete with the C# class library.

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

[pyrrho]

which makes me wonder... is what we want for C++ to catch up is a way to specify your coding standard to a tool that can check source to see... e.g. if a company uses a class system which supports a pointer free paradigm at the app level in C++, they specify their standards in a documents, and this would be a tool to check the code for compliance.

I understand this problem... C++ is multiparadigmed, but a program should adopt a single paradigm.

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

[Wolfier]

>Yeah and the compiler, well theyre not smart at
> all, i mean I have to code someconstantvalhere
> == variablevalue becuase the compiler cant
> check the == properely. More C++ issues.

It is not a C++ "issue". It is a feature that every expression can be evaluated. So "if (c=3)" will evaluate to "if (3)" after the assignment.

Again it boils down to features vs foolproof. If I have a choice, I'll stay away from C and Java, then choose something somehow higher level than C++ but lower level than C#.

Maybe Objective C will fit the bill.

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

[Wolfier]

How about
// C++
list<string> strings;

copy(strings.begin(), strings.end(), ostream_iterator<string>(cout, "\n"));

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

[Khelder]

That's a interesting idea. I think it would make C++ safer. It seems to me that it's better to start with a language that's safer in the first place, but I haven't really thought through what would be involved in the kind of tool you describe.

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

[Anonymous Coward]

It is not a C++ "issue". It is a feature that every expression can be evaluated. So "if (c=3)" will evaluate to "if (3)" after the assignment.

And anyone who thinks that's a bug not a feature doesn't understand the point:

while (c = getc(f)) {
do_stuff (c);
}

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

[pyrrho]

I have not thought of it too much either, though I know some issues would be easily checked (like preventing use of pointers outside low level classes... etc.), harder would be a declarative language for defining the acceptable paradigm, not leaving paradigms out, and probably a lot of difficult special cases of things that are part of people's current standards which would be hard to check with such a tool.

However: the advantage of not having a language built to the safe paradigm is that C++ and this tool would allow a choice between multiple paradigms (infinite? at any rate a large number). It would be meant to prevent mixed-paradigms on a module by module basis (e.g. if you have a pointerless paradigm you were using at the application level, you probably don't want that in the system classes used, etc.)

lint++?

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

[Anonymous Coward]

Java and C# are modern/designed languages, C++ is not. Java and C# are designed for you to be productive and write robust applications, enabling you to spend more of your time on bussines logic and usability - C++ is made for selftorture, you spend way too much time dealing with tricky techincal/language/debugin stuff. If you consider all 3 of them to be more or less the same "high level" languages, then I doubt you have much real experince with C# or Java.

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.

[leandrod]

> The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with.

References? Who's precisely hostile, and how?

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.

[scrytch]

> they're even openly hostile to the GNU efforts that they're competing with.

Because RMS came down from the mountain and decreed "wait for the great CLR that GNU will bestow on you, stop wasting your time on silliness like trying to bootstrap the project in C#, that requires you to dirty your hands with the impure Microsoft toolchain."

Last time we heard that sort of commandment to wait, it was about HURD. Is it any surprise that Mono continued to strike out on their own?

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

[Anonymous Coward]

Mono and dotGNU have different goals. They are not "hostile".

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

[Anonymous Coward]

The Agreement is called the ECMA/ISO standards body, which part of the STANDARDS body do you have disagreements with? After all they also cover C/C++ standards, dont forget C++ has only been standard since 1998 (officially)?

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

[Anonymous Coward]

Standards based on patents are not new at all. Here's a few - mpeg3, mpeg 4, AAC, AC3. Just because a patented technology has been adopted as a "standard" by some organization does not mean the patents are now freely licensed.

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.

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

[leandrod]

> This slashdot posting is one of several instances in which Miguel has publicly spread FUD against Portable.Net

Very interesting posting, and an eye-opener. I for one don't care about non-copyleft software, and I had assumed Mono was GNU LGPL.

So the question now becomes, I was planning on a Mono port of Alphora Dataphor, which unfortunately is proprietary, but it is the only package I found capable of doing what I want in the middle term. I haven't started anything yet, but I was under the impression that Mono was the way to go, with their implementations of a PostgreSQL adaptor and ASP.Net. Does DotGNU and Portable.Net could support such a port in, say, one or two years from now?

That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU and you reading Rotor code. And there isn't any specific answer attached to this... would you care to answer in detail now, or provide an URL?

Thanks for the eye-opener.

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

[RdsArts]

Applying for a standard is not a agreement to license a patent or keep something patent-free, but a agreement to set one standard ruleset for a language/widget/etc.. Hence, why it's a standard. ;)

IIRC, the standards body .Net works with dictates a license fees for the standard's patents be small, but still a small price on the patents still puts the code into a unfree and unFree condition. If they charged for the patent, I don't even know if the source could remain open, but IANAL YMMV FYI TGIF ABS standard.

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

[prockcore]

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.

Why is this modded insightful? You can't patent an API.

If MS holds patents that could apply to Mono, they certainly would apply to Java as well.

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

[bizcoach]

implementations of a PostgreSQL adaptor and ASP.Net. Will DotGNU Portable.Net support such a port in, say, one or two years from now?

Yes, definately.

That said, in the middle of FUD that post has some interesting claims, like impractible goals of DotGNU

I'm not sure what you mean with "impractible goals of DotGNU". Fundamentally I'd say that there are two types of goals: "essential goals" and "dreams". With an "essentail goal" I mean a goal which is essential for making the project a success; if we don't reach that goal, the project hasn't been fully successful. For DotGNU, "making it easy to port apps that were written for .NET so that they become truly portable with DotGNU Portable.NET" is an "essential goal" in this sense. With "dreams" on the other hand I mean the type of goal that would be great to achieve, but where it's not really essential to achieve it. I have lots of DotGNU-related dreams, probably most of them will never get realised, but some will, and I think there's nothing wrong with that.

Maybe you mean Miguel's statement "the DotGNU team wanted to invent a new virtual machine that supported Java and .NET at the same time"? That dream is not as impractible as it might appear at first. Read this. We do have a working runtime for IL which has been designed in such a way that there no serious obstacles (besides lack of volunteers) against adding support for JVM bytecode into this same runtime engine. Miguel criticises the JVM bytecode support as "slow, untested, and very broken"; I'm not interested in debating these claims. This JVM bytecode support is not something that we publicise as a feature; rather it's a proof of concept showing that with pnet's design it is possible to implement this, and an invitation to anyone who is interested in JVM-IL interop to come on board and work out the details.

reading Rotor code

Miguel's statement "Pnet follows a different approach: read Rotor, and do a new implementation of it" is mostly FUD. The truth of the matter is that Rhys has asked Eben Moglen, who is the General Counsel of the Free Software Foundation (and also the author of the GNU GPL and LGPL) for legal advice concering the question of whether looking at Rotor code is ok, and received the following response (posted with a bit more context in the pnet FAQ):

My advice is to tell people to code where possible from the ECMA standard. Where (which is likely to be everywhere), ECMA is insufficiently descriptive to create interoperable code, it is acceptable to read the source of the Rotor implementation. Notes taken in the course of reading that source should be made in pseudocode, so that programmers do not copy snippets of the Rotor source as aides to their memory. We want every line of code in our projects to have come out of the original invention of one of our coders, having been expressed in his or her own way. Ideas abstracted from the Rotor implementation should always have been put in our programmer's own "words," because copyright protects expressions, not ideas.

We follow this advice.

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

[leandrod]

> Yes, definately.

Hope so. I am looking now for a systems programmer, and that will be one of his tasks, perhaps the main one in a few months. Alphora Dataphor is really such an interesting tool. Now if I could convince authors to go free...

> it is acceptable to read the source of the Rotor implementation

I see. But somehow I'd feel safer if a policy of not looking at all was possible.

All in all, your posts have made me tend to prefer your efforts if and when we come to porting time.

Is there anyone keeping scores on how near each effort is to provide some real portability, especially for database apps and systems programming tools?

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

[bizcoach]

Is there anyone keeping scores on how near each effort is to provide some real portability, especially for database apps and systems programming tools?

Alas, no. Of course this would need to be done by someone who is reasonably objective (in particular not someone who is emotionally attached to either project), but if done well such comparitive reports would certainly be valuable not only to users but also to both projects.

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

[Anonymous Coward]

Very interesting posting, and an eye-opener. I for one don't care about non-copyleft software, and I had assumed Mono was GNU LGPL.

So tell me, what copyleft windowing system is it that you use?

Oh, there isn't one. My mistake.

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.

Re:XUL

[Anonymous Coward]

At least the python binding is dead/in coma long time ago.

Re:XUL

[Trejkaz]

And Java, for that matter. Actually any object in any language supporting XPCOM, right?

Well..

[Anonymous Coward]

I hate to say it, but I feel it needs
to be said:

Ocaml.

Re:Well..

[Anonymous Coward]

I tried to learn it but it is just too ugly. Worse than Perl.

kylix

[Cynikal]

what? why is no one suggesting Kylix? then i could recompile with delphi and have Gnome running on my windows boxes too :)

Re:kylix

[Anonymous Coward]

what? why is no one suggesting Kylix?

Cause kylix isn't free as in freedom.

Re:kylix

[turgid]

So you can target x86 CPUs or the .NET CLR. Great. Now what about the people running Linux on PowerPC, ARM, SPARC, MIPS, Alpha, PA-RISC, 68k.....?

Re:kylix

[Cynikal]

Borland(R) Kylix(TM) 3 Open Edition delivers an integrated ANSI/ISO C++ and Delphi(TM) language solution for building powerful open-source applications for Linux,(R) licensed under the GNU General Public License. (from the website)

its only "not free" if you're developing closed source for comercial use.. last i heard, gnome and KDE were open source, so i don't see how that conflicts with anything here

Re:kylix

[Anonymous Coward]

its only "not free" if you're developing closed source for comercial use.. last i heard, gnome and KDE were open source, so i don't see how that conflicts with anything here

Show me the source code of Kylix. Oops, you can't.

Got that?

A GNOME Developer speaks. Cut&Paste from OSNew

[Anonymous Coward]

That's quite an facile editorial but you can't expect better from normal users. My screenshot looks better than yours. Evolution is better than KMail, GNOME looks more polished than KDE and so on. I do use XChat, Abiword, Rhythmbox.... ...usually you get stuff like these from normal users. And this is ok since you can't blame them for stuff they simply don't know about or don't have a slighest knowledge about.

Such editorials are hard to take serious since they are build up on basicly NO deeper knowledge of the matter. Most people I met so far are full of prejudices and seek for excuses or explaination why they prefer the one over the other while in reality they have no slightest clue on what parameters they compare the things.

If people do like the gance ICONS over the functionality then it's quite ok but that's absolutely NO framework to do such comparisons.

I do come from the GNOME architecture and spent the last 5 years on it. I also spent a lot of time (nearly 1 year now if I sum everything up) on KDE 3.x architecture including the latest KDE 3.2 (please note I still do use GNOME and I am up to CVS 2.6 release myself).

Although calling myself a GNOME vetaran I am also not shy to criticise GNOME and I do this in the public as well. Ok I got told from a couple of people if I don't like GNOME that I simply should switch and so on. But these are usually people who have a tunnelview and do not want to see or understand the problems around GNOME.

Speaking as a developer with nearly 23years of programming skills on my back I can tell you that GNOME may look polished on the first view but on the second view it isn't.

Technically GNOME is quite a messy architecture with a lot of unfinished, half polished and half working stuff inside. Given here are examples like broken gnome-vfs, half implementations of things (GStreamer still half implemented into GNOME (if you can call it an implementation at all)) rapid changes of things that make it hard for developers to catch up and a never ending bughunting. While it is questionable if some stuff can simply be fixed with patches while it's more required to publicly talk about the Framework itself.

Sure GNOME will become better but the time developers spent fixing all the stuff is the time that speaks for KDE to really improve it with needed features. We here on GNOME are only walking in the circle but don't have a real progress in true usability (not that farce people talk to one person and then to the next). Real usability here is using the features provided by the architecture that is when I as scientists want to do UML stuff that I seriously find an application written for that framework that can do it. When I eye over to the KDE architecture then as strange it sounds I do find more of these needed tools than I can find on GNOME. This can be continued in many areas where I find more scientific Software to do my work and Software that works reliable and not crash or misbehave or behave unexpected.

Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.

We still have many issues on GNOME which are Framework related. We now got the new Fileselector but yet they still act differently in each app. Some still have the old Fileselector, some the new Fileselector, some appearance of new Fileselectors are differently than in other apps that use the new Fileselector code and so on. When people talk about polish and consistency, then I like to ask what kind of consistency and polish is this ? We still have a couple of different ways to open Window in GNOME.

- GTK-Application-Window,
- BonoboUI Window,
- GnomeUI Window,

Then a lot of stuff inside GNOME are hardcoded UI's, some are using *.glade files (not to mention that GLADE the interface buil

Re:Havoc, the guy who fucked GNOME

[Anonymous Coward]

If they worked on KDE we by now would have a far better Desktop..

Would we? It seems to me that a lot of effort on KDE is wasted by continually reinventing the wheel, or just wasted with downright complete rubbish which shouldn't be there in the first place.

Exhibit A: KPaint. What the hell were the KDE release team even thinking? It doesn't work. What is doing in KDE?

Exhibit B: Kview & Kuickshow. KDE2 had KView, which worked, had a nice interface and was very useful. Now we have Kuickshow which is klunky, over engineered and less useful than KView. It takes a lot longer to load, too. Why?

Exhibit C: KBiff. KBiff was damn useful when I was running KDE1 all those years ago. Where is it now? Oh, it died a long time ago with the change to Qt 2.x Droping features like that is just bad.

Maybe if the KDE guys would spend some more time and actually invest themselves in less duplication and wasted effort instead of worrying about whatever GNOME are doing, wKDE would be a far better Desktop?

Reply: How about still using C

[Adhemar]

It's about using the right tool for the right job. Havoc isn't proposing the usage of C in the Linux kernel or even in the X Window System.

Java and C#/.NET are great tools for coding high-level applications. Development is a lot easier, since you don't have to spend hours looking for those small memory leaks. It's a few times faster, hence RAD: Rapid Application Development. (Mikael Hallendal described how his RSS/RDF-reader BLAM! was ready in 1 week.) Arguably, it's better maintainable.

Indeed, there's a performance price to pay.

There are already a few small GNOME-based applications written in C#: RSS/RDF reader BLAM!, WoodPusher chess game, Muine music player, ... At some point, GNOME will have to decide if such applications can be part of GNOME, and I agree that GNOME should choose a high-level language and environment as their default high-level language and environment. That doesn't mean GNOME should drop C.

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

[drooling-dog]

Why are the end-users asked to know what their OS is?

So your Mac binaries are working just fine on your Windows box, are they?

Why should I have to know how to compile (or even know what "compile" is)?

Well, you don't. Just about every app I can think of is available in binary form (e.g., as an RPM file); all you have to do is download and install.

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.

But unless they have a decent mechanic to maintain and repair it, they won't for very long. It's just a fact of life that those who refuse to learn to do anything for themselves are going to find themselves limited in many ways and dependent on others. That's true whether we're talking computers, cars, plumbing, or brain surgery.

I don't think you're upset because you can't figure out how to download and install a binary for a Linux app; I'll bet you can if you try. What you resent is that the guy down the street can fix his car in his own garage while you have to take yours to the shop for every oil change. Microsoft "welds the hood shut" for everybody, so you'll never have to envy those who are willing and eager to learn.

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.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

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

More to the point it makes it very difficult to produce commercial software for Linux. For example, in 1996 I bought a copy of Lotus 123 this still installs and works perfectly on WinXPSP1.

The same cannot be said of my Linux version of Applixware bought for $100 only 2 years ago, this is now a coaster and will not install/run on any current Linux version, just crashes in a heap asking for various long obsolete libs

Re:Why Linux will never beat Microsoft or Apple

[johnnyb]

As for the dependency issue, it isn't really a Linux problem per se. Windows has the same dependency problems, they just have a lot of third-party developers who fix them for you. InstallShield and WISE being the two main examples.

If you package your program correctly or statically link it, you have none of these problems. This is why Mathematica works for every known distribution out there - they just package their code correctly.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

So install the libraries. RedHat calls them whatever-compat and Debian has a section called oldlibs.

You can even add libraries from previous versions (I have done it in Debian, having ncurses 4 from Potato on Woody).

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

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)?
...
We have people who can barely use Windows or MacOSX, they would have no chance in hell with Linux.

Maybe Linux and BSD shouldn't have to tend to this user base.

I think it's funny that you mention BSD. The people that use BSD aren't the type that are going to expect to download the latest CoolThing.exe from www.aol.com and "just have it work." I can't ever picture my grandma using OpenBSD. I shouldn't have to picture it; OpenBSD does very well at keeping its user base happy, and filling the niche for what it's supposed to do. I really don't think it'll ever be a GUI OS that any Windows user can sit down at and use out of the box. That isn't the project's goal at all. And there's no reason that it should be.

Linux, on the other hand, has distributions which do aim for something like that. But you have to understand that for every distribution that aims to create a friendly GUI experience, there are probably several distributions that can be installed on machines without monitors, running on processors you might not have heard of.

The funny thing about Linux and the people that write about it is you have so many "armchair OS architects" that have a very narrow view of what an OS and a computer is. They can only see a computer for what they personally use it for. So many people want Linux to become the next Mac OS or the next Windows, that they forget that there are many satisfied Linux users today, and many uses of Linux that the armchair OS experts have not personally envisioned.

So when people talk about "streamlining" Linux to make it into a "Windows alternative..." Sigh.

Re:Why Linux will never beat Microsoft or Apple

[WankersRevenge]

Some of us don't care about the hood being welded shut. Some of us don't mind paying a mechanic. I'm saving time which in truth, is more valuable than money. Installing programs in windows is easy. Just double click. In linux, welcome to rpm dependancy hell. I'd rather deal with the former until the latter works itself out.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

Hear hear!

This is also precisely why there is no serious game development for Linux, as per previous slashdot article.

There is too much tinkering in underlying APIs and not enough standardization for binary compatibility.

The first goal for a better desktop should be--and not to troll---to FEATURE-FREEZE all development of gtk/qt/gdk-pixbuf/gnome/kde/glade/pango/etc.etc.et c.

For crying out loud, how many new ways do we need to pop a bitmap on the screen and bind it to an action? Freeze the standards so they can BE STANDARDS!

And then maybe, just maybe, we can go back and clean them up. Bugfixes. Maybe consolidate where effort is duplicated. Maybe *gasp* rewrite for speed.

You will never have serious binary development until there is a singular simple, robust API/ABI for doing things that is truly standard across all Linux machines.

Re:Why Linux will never beat Microsoft or Apple

[mrogers]

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.

...and when the car breaks down or they want to upgrade it, they go to a mechanic. The few that try to do it themselves either know what they're doing or break something pretty quickly.

Computers can and should be easy for non-experts to use, but maybe they'll never be easy for non-experts to maintain. We should stop pretending that PC maintenance can be done through a pretty point-and-click interface that requires no knowledge of computers, because that's nonsense. When things break you have to understand how they work to get them working again.

Hopefully users will get used to the idea that when they want to change something on their PC they should take it to an expert (even if that's their nearest /. reading friend or relative). To support this, desktop systems should ship with separate "user" and "maintenance" accounts. User accounts can't install software or hardware or change settings that affect other users. Maintenance accounts can change settings, but don't have access to other accounts' personal data (which makes them different from the current administrator/root accounts). As well as the main maintenance account it should be possible to generate "one-shot" accounts with more limited capabilities, so a user can feel comfortable allowing an expert to login remotely.

Of course some people will maintain their own PCs, but those who don't intend to do so shouldn't have the capabilities enabled - it leads to problems like spyware and trojans which actually make life more difficult for non-experts.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

I'll bet you never heard of apt, apt-rpm, yum, yast, urpmi and associated solutions then?

Re:Why Linux will never beat Microsoft or Apple

[westlake]

It's just a fact of life that those who refuse to learn to do anything for themselves are going to find themselves limited in many ways and dependent on others. That's true whether we're talking computers, cars, plumbing, or brain surgery.

It's tempting to respond with a one-liner here, but no.

What you resent is that the guy down the street can fix his car in his own garage while you have to take yours to the shop for every oil change.

I'll pass on crawling under three tons of metal to save a few bucks.

Microsoft "welds the hood shut" for everybody, so you'll never have to envy those who are willing and eager to learn.

I enjoy relaxing behind a computer. I do not want to make it an all-consuming hobby. Microsoft exposes enough so that I can do the minor tweaking that interests me. But the less time spent under the hood the better, as far as I am concerned.

Re:Why Linux will never beat Microsoft or Apple

[An Onerous Coward]

Just to be pedantic, I would point out that it doesn't matter how skilled a brain surgeon you decide to become; if you need brain surgery, you'll need someone else to do it.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

Ideally, the libraries wouldn't change unless there were something wrong with them. Some of these libraries have been immature in some places, and some of the improvements have been very necessary. Of course, there will need to be more changes in the future. Not all of them, by the way, end up as binary incompatibilities.

If you want, you can always keep the old versions of the libraries around on your system. For example, Gtk+ 1.2 can happily co-exist with Gtk+ 2.x. There is no problem with running them concurrently.

Re:Why Linux will never beat Microsoft or Apple

[An Onerous Coward]

Well, thank God we have you to put it all in perspective for us. Frustrated because there's no way to hack the functionality you need into IIS? What the hell do you need it to do that for? westlake doesn't. Suspicious that the bug you keep running into is coming from the Visual Studio compiler, but can't check the source to prove it? Why would you ever want to look under the hood? westlake doesn't.

Be like westlake. If Microsoft hasn't given you a way to do it, it doesn't need doing. You don't want computing to be some sort of all-consuming hobby, do you? Be like westlake, and get a life.

Sorry, but you need some perspective yourself. "Not important to you" is not the same as "not important."

Re:Why Linux will never beat Microsoft or Apple

[Hard_Code]

Wow you're right. We should design software to be broken and hard to use from the start! That will prevent people from running malicious software. Of course it will prevent people from running good software also. And nevermind security settings, that couldn't be the problem.

Re:Why Linux will never beat Microsoft or Apple

[Hard_Code]

Fundamentally: 10 poor (in different ways) solutions is not equivalent to 1 good solution.

Re:Why Linux will never beat Microsoft or Apple

[drooling-dog]

Some of us don't care about the hood being welded shut.

That's fine; to each his/her own. But my point is that maybe you don't have to go "under the hood" with Linux nearly as much as you assume (or at all). The major distributions make installations and upgrades pretty painless. I used to run Windows, too. I have non-techie friends and relatives who still do; they usually assume that Linux is "too difficult" for them, but when I show them how I use it they're at a loss to tell me exactly why. It seems to boil down to things just being a little different; they've figured out some habitual ways of doing things and they'll resist having to repeat that process in a new environment. It would be much the same migrating in the other direction.

Re:Why Linux will never beat Microsoft or Apple

[drooling-dog]

if you need brain surgery, you'll need someone else to do it.

Wish I'd know that a few days ago...

Re:Why Linux will never beat Microsoft or Apple

[westlake]

Well, thank God we have you to put it all in perspective for us. Frustrated because there's no way to hack the functionality you need into IIS? What the hell do you need it to do that for? westlake doesn't.

The parent was speaking about users , remember? Those folks who will never, ever, be found hacking into a server.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

Why then, do you feel compelled to share these insights in the Developers section?

I'm truly nonplussed.

Ok, so maybe you saw the OP on the frontpage and not in the section, but again: It's about coding; essentially only about what's "under the hood". And you're posting "just double click"?

I can't for the life of me grasp how Havoc's thoughts on high-level language migration in open source desktop development, and the subsequent discussion here on developers.slashdot.org, would be interesting enough to spend time reading / posting to - if you don't enjoy coding and want to learn as much as possible about it.

If you don't enjoy coding (which, reading your post, you obviously don't), maybe you want to reconsider were you spend your online time(?)

The Developers section is inhabited by people who code (and are dying to learn how to do it better), rather than wait until "[Linux] works itself out".

If/when curiosity sets in about what's beneath the hood, you'll find this section a most interesting place.

Greetings from under the hood.

Re:Why Linux will never beat Microsoft or Apple

[eloki]

...and when the car breaks down or they want to upgrade it, they go to a mechanic. The few that try to do it themselves either know what they're doing or break something pretty quickly.

Exactly. Most of them aren't changing the oil or installing new radios etc. They just use it, they don't try to change it. Really both Linux and Windows are much better in that regard - "oh you want to install a better radio? that means you need better cables.. I'll put that in for you!"

When cars do that, I'll consider them as good as computers in this respect.

Re:Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

Graphical installation programs are definitely the way to go for most desktop users. Ideally the same installer program for all applications on your OS and the minimal amount of configuration.

Installation is one of the most important parts of the user experience for any application.

Lindows has a nice "Click n Run" installation of programs - unfortunately you have to pay money to subscribe to it.

I guess the reason this is not more popular for Linux is that applications are rarely standalone - they almost always need other libraries to work, although if they're GPLed there's nothing to stop you distributing these too.

Re:Why Linux will never beat Microsoft or Apple

[Stevyn]

That is retarded.

Saying it's a good thing that software is hard to install because then people have to invest a lot of time in installing it so they only ever install the stuff they actually use often is fucking dumb.

Mod me down, I don't care, that's retarded

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.

Re:What happened...

[BCGlorfindel]

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.

And this is precisely the reason moving Gnome to Mono is a good idea. The single biggest advantage of the CLI over the JVM is that you can compile multiple languages into it. The Ximian team can develop gnome in C# and allow complete access to the api's to any language for the cost of building a mono compiler for the language. API update changes for each language would become a thing of the past. I really think the Ximian guys are on the right track here to allow better support for outside developers.

Re:What happened...

[Anonymous Coward]

The CLI concept is overblown. The problem with the CLI is that those multiple languages tend to be the exact same code except with minor syntax changes (i.e. new line instead of a semicolon to termintate statements). Big whooptie fucking do.

Re:What happened...

[Bluesman]

You're right. I just don't have the confidence that the Gnome folks will see this through to completion.

This is essentially a complete rewrite that Havoc's proposing. How many of those have they had? How many have been finished successfully?

>for the cost of building a mono compiler for the language.

Therein lies the problem. This is a huge cost. It remains to be seen if this can be done for some languages.

But if they succeed, that would be great. I hope they choose Mono, if and when they do this. Miguel is doing some great things.

Re:What happened...

[JanneM]

Um, the Perl bindings are pretty complete and very up to date (the current prerelease stuff covers GTK2.4, for example).

Re:What happened...

[Anonymous Coward]

Stuff like corba just isnt usefull if you want to be productive. I have programmed ASP.old for years. In theory i had access to heaps of components using COM, but since they were all built by different teams, using different languages and different ways of documenting, I always felt like Sherlock Homes spending most of my time digging for information. Its damn unproductive. A complete/designed/consistantly documentet API such as the one in Java or .net or mono is what makes programmers productive.

That's great if you ignore interoperability

[yoz]

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

Do not integrate, do not unify, be free.

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

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

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

Re:That's great if you ignore interoperability

[Jacek Poplawski]

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

Yes. Application with best UI will have bigger userbase. Applications with small userbase could change their UI then.

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

If you have problems configuring your word processor - try another one. Better will win, worse will lose. Evolution and free market. It works much better than any general regulations. And why this kind of freedom is called "communism" by some people?

PS. And please no examples of RFC here... :)

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.

Re:YES

[BigGerman]

Great comments. Someone with balls, please mod this up.

Re:YES

[hyperstation]

this is the best analogy i think i've seen yet...

i've been afraid of and skeptical of all this before, but it's not just a particular company's idea - it's a paradigm in the way software will be developed in the future, and by "future" i don't mean 100 years, i mean the next few.

C is not dead, it only takes on new life as other, more suited tools (rooted in c!) move in and fill in the pieces.

mod parent up, it deserves to be seen...

Re:YES

[Anonymous Coward]

A consistent platform? What do you mean? Everybody should pick one thing and then forget about all that other stuff they were doing? How ridiculous.

If you want a consistent platform, how about SWIG? No need to pick one of Java, Mono, Parrot, etc. Use them all.

Python and large desktop apps

[Synn]

I'd be curious to know why the auther thinks Python isn't a good language for writting large desktop apps.

Seems he's pretty quick to rule out every language except for Java and .NET.

Re:Python and large desktop apps

[mrkurt]

As much as I love Python, I think Havoc is right up to a certain point-- apps run much slower in Python than in other languages. And I think that he really is ruling out moving GNOME away from C/C++ because .NET is proprietary and Java is mostly proprietary in nature.

Re:Python and large desktop apps

[uberchicken]

I thought exactly the same thing. I admit that I feel the same way he does, but I wouldn't be so dismissive without more in-depth analysis of those languages.

In fact, the whole discussion made me wonder about Parrot being the CLR/VM that we're looking for. A true libre multi-language platform.

Re:Python and large desktop apps

[Anonymous Coward]

How about limiting discussion to languages and runtime environments that actually exist? (not a pre-pre-alpha)

Re:Python and large desktop apps

[IamTheRealMike]

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.

Programming is hard. It's an unnatural thing for the human mind to do. The more code can be automatically verified and checked, the better IMHO.

Python has a few other problems. It's (a) slow even with tools like Psyco and (b) has a wierd non-C like syntax which is a bit offputting for people who are used to C++/Java/C# style languages.

Re:Python and large desktop apps

[krumms]

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

This is such a non-issue. Would you not use C because it has weird non-x86 Assembly syntax?

Re:Python and large desktop apps

[bucknuggets]

> 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. In theory perhaps. But I'm seeing python used in larger & larger applications - and believe any problems created by dynamic typing are more than compensated for by its simplicity. > Python has a few other problems. It's (a) slow even with tools like Psyco Really? Makes you wonder about claims like - "visual basic is what really made windows a success". How could such a slow, interpreted language like vb work so well for windows - on 486-66s? > and (b) has a wierd non-C like syntax which is a bit offputting for people who are used to > C++/Java/C# style languages. any c++/java/c# programmer worth his salt should be able to pick up python almost immediately. It's simple and intuitive. And the use of whitespace to enforce nesting consistency hardly makes the syntax 'weird'.

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?

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

Re:Python and large desktop apps

[IamTheRealMike]

You find having sex as natural as programming?

I'm unsure whether I should feel sorry for your partner or not...... ;)

Re:Python and large desktop apps

[Anonymous Coward]

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

I once cut and pasted a bunch of numerical C routines into Python without hardly any modifications to the syntax at all. Now with some other languages, I'd have to add a lot of '$' for example. Granted, numeric works is an exception. Nevertheless, I feel close to C when programming in Python which I like. But others may have a different experience of course.

Re:Python and large desktop apps

[cpeterso]

unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep

Re:Python and large desktop apps

[mod12]

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.

What makes a type error "nasty"? It is not the degree to which the types are different, but the potential consequences of overlooking their difference.

In my view, the principal practical advantage of static type checking system (as implemented in current languages) is their ability to catch boundary conditions. Have you ever called a Python method and forgot that it might return None? Your program works fine for a while, but it will eventually trip because you forgot to test if the return value was None. It will probably just crash with an uncaught exception, but in the process may mangle or lose data. (Users tend not to like that. :)

In general, when boundary conditions are ignored, any degree of havoc can potentially result because your code is being interpreted in a way you never intended.

One answer is exception handling, and you can sometimes use this to salvage yourself from utter disaster, but if you are catching an exception that arose from a boundary condition you didn't think of, then your exception handling is too broad!

For typical programs written in a scripting language, the coder may actually want the program to just terminate on all unconsidered boundary cases. But when a script grows into a useful application (perhaps one that is run automatically by a cron job or a web server), it is eminently useful to have some sort of guarantee that it won't crash.

Re:Python and large desktop apps

[Anonymous Coward]

Now let me say it S-L-O-W-L-Y
Java is NOT INTERPRETED
it uses a PROFILING OPTIMIZING JIT COMPILER

Re:Python and large desktop apps

[tal197]

What makes a type error "nasty"? It is not the degree to which the types are different, but the potential consequences of overlooking their difference.

Yes, that's exactly how I'd define 'nasty'.

In my view, the principal practical advantage of static type checking system (as implemented in current languages) is their ability to catch boundary conditions. Have you ever called a Python method and forgot that it might return None? Your program works fine for a while, but it will eventually trip because you forgot to test if the return value was None.

Umm. Java does the exact same thing, except it calls it Null instead of None.

It will probably just crash with an uncaught exception, but in the process may mangle or lose data. (Users tend not to like that. :)

For desktop applications, exceptions are caught at the event loop and displayed in a dialog box. The application continues running, without losing data (in my experience) and the bug gets reported. This is usually the case with Java too, though.

You can usually classify type errors reported by the compiler into:

• Errors you would have immediately spotted after the compile when you ran the code the first time.
• Errors only due to the static checking system (eg, forgetting a cast), which don't affect dynamically typed languages in the first place.
• Errors you would have spotted later, but which would have been just as easy to fix then as now.
• Errors that would have caused you problems if the compiler had missed them.

I find type errors rarely fall into the last group.

Re:Python and large desktop apps

[tal197]

I've looked at the output of some code from psyco and it looked just like C

Oops, I meant pyrex, not psyco. Haven't looked at psyco yet.

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.

Re:So the goal really is to follow Windows?

[Anonymous Coward]

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.

Two things: 1. Python is not a "huge win" over C#. In many ways it seriously inferior... starting with it's hideous grab-bag of functional, procedural and oo language features with little or no thought. 2. THIS ISN'T JUST ABOUT C#. This is about Mono... the VM. Python can be targetted to the Mono VM too... as can any other managed language.

Re:So the goal really is to follow Windows?

[Anonymous Coward]

It seems the Linux GUI developers have been in the congregation of the church of MS Windows for some time now, and yes, they are indeed faithful followers. DotGNU and Mono aren't the only examples. Many have touted Gnome and KDE as some kind of alternative. They're in self denial about the fact that these both have the stink of MS Windows all over them as well. The Linux GUI people will try to hack something to the MS Windows standards and Microsoft will just tweak things to make sure software ported from MS Windows to Linux will not work properly as they've always done.

I've seen someone state here that BSD people love Unix while Linux people hate Windows. That's definitely wrong. While Linux people may hate Microsoft, they're just obsessively in love with MS Windows. They have serious Windows envy. Personally I find the whole issue disheartening. I don't see a time when the Linux people will ever come up with a nice desktop---they absolutely refuse to leave the MS Windows interface they grew up with behind.

Re:So the goal really is to follow Windows?

[hackrobat]

See JWZ's rant about Java.

Now, here's what Python has that Java doesn't:

• Local functions,
• lambdas,
• "everything is an object",
• automatic invoking of getter-setter methods,
• static methods are really class methods (and not merely global functions),
• two (byte, or otherwise) arrays compare equal if they have equal contents (and therefore they also work fine in hashtables),
• separate types but common interface for ascii and unicode strings,
• multiple inheritance (programmers are not dumb),
• weakly typed (solves 4-5 of his problems),
• methods don't really "belong" to classes (in his terminology),
• printf-like formatting is supported :-)

Actually, J2SE 1.5 already fixes a lot of these things in Java.

About static typing: Bruce Eckel very recently wrote about what he thinks about Python's typing, what he refers to as "latent typing". See my related blog entry.

We've started believing that static typing has a low benefit/hassle ratio.

See also: The Great Computer Language Shootout. (Python comes out way too bad in performance.)

Re:So the goal really is to follow Windows?

[Anonymous Coward]

I know zero programming, and even I was able to fix a minor python bug it some software I dl'ed.

Re:So the goal really is to follow Windows?

[Rothron the Wise]

Actually, J2SE 1.5 already fixes a lot of these things in Java.

Yeah. And don't you think JWZs rant is fairly dated now? A lot of his points are no longer valid, and more than a couple of them only reveal that he's still trying to code C in Java.

Re:Eeek... Joe User

[Anonymous Coward]

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

I do agree with that, but I will even go further and say that since there's so much crap to learn in the first place, Joe User won't even *TRY* to get into Linux because of that.

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

Re:Java, still around eh?

[meadowsp]

Just a question, how do you know whether it's Java running on the server?

Re:Java, still around eh?

[jswalter9]

The biggest reason that Java is a resource hog on Linux is that it's current implementation is a hack. Using shared memory segments to communicate between process threads is not how the runtime was intended to be implemented. Now that 2.6 has *real* threading, we'll see what Java can do in Linux with green threads. I think many people will be surprised. (I've personally surprised a few Java bigots where I work by outpacing their C++ and Objective-C code with Java solving the same problems, but that's a single-threaded server process with no GUI.) IMHO, Java is the right direction, and gcj is my greatest hope.

Re:Java, still around eh?

[cygnus]

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

well, if you lump all the alternatives into one category, it's not surprising. all you've said there is that java doesn't have a simple majority.

Maybe we should Lobby SUN

[barcodez]

If Sun were to release the Java (spec.) on an Open Source compatible license then we would be laughing. We wouldn't even need an implementation as there is one: blackdown.

For GOD'S SAKE

[0x0d0a]

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

AAAAAAAAAAAAAUUUUUUUUUUUUUUUUGGGGGGGGGGGGGGGGHHH HH HHHHHHHHH!

What is *wrong* with you people?

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

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

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

Re:Havoc?

[larryk]

From his website: http://ometer.com/

My full real name found on my official government documents is "Robert Sanford Havoc Pennington." Everyone calls me Havoc, and always has. I didn't make it up. There isn't a cool story about it, my parents are just weird. It is not a nickname. No, I do not wreak havoc, usually. Yes, I have heard any and all jokes you can think of about this.

Yeah, lets all rally 'round Havoc Pennington.

[Anonymous Coward]

Letting Havoc Pennington decide what the Linux desktop should look like is like hiring Stevie Wonder for an interior decorator--He may be talented, but there are areas he should just simply stay away from. Far away from. Deciding standards for others, being among them.

Long story short, Pennington simply doesn't get the big picture of what the Linux desktop needs to be. For example he thinks having multiple, competing standards for GUI layout is a good idea. Ding ding ding ding! Hey Havoc, here comes the Oxymoron Train! "multiple standards"?!

Here's a real revolutionary idea...Instead of spending years trying to mimic every aspect of the Windows desktop, we build one of our own, with our own ideas! (*gasp*) !

OK, you convinced me; here's my contribution

[Anonymous Coward]

This article convinced me that it's time to start taking gcj seriously, so I'm going to add gcj support to my 'crosstool' package (which is just a simple, convenient way to build a gcc+glibc toolchain). Maybe that'll help more developers consider using Java.

Also, a couple years ago, I experimented with gnome's corba implementation, Orbit. It was pretty darn lightweight and fast. Since then, Orbit has made so much progress, maybe I should have a look at it again, and see how hard it'd be to add support for that to crosstool, so Corba could be an easy option for people using crosstool-generated toolchains.

Qt? anyone

[Anonymous Coward]

If the gnome guys are considering all the new languages, libs and unproven vm technology, maybe they could also do qt bindings while at it. Please, this is not a flame. QT is there. The kde felas have already embraced Gtk. Gnome should do the same.

Any article about linux desktop development should talk about both qt and gtk if it is to be taken seriously.

Re:Qt? anyone

[fozzmeister]

If you'd googled before posting you would have seen http://qtcsharp.sourceforge.net/

Re:Dump X11

[Chalybeous]

Good call on bringing up the point about the window managers running on top of a GUI. I never actually knew that...
You've managed to echo my feelings precisely AND teach me some new info about Linux. Thanks for the insight!

Re:A GNOME Developer speaks. Cut&Paste from OS

[seguso]

Man, what you wrote is almost poetic.

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.

Re:some postings here scare me

[Anonymous Coward]

When you say, clean OOP, you must mean, rigid, classical OOP with single inheritance for object-classes and multiple inheritance for abstract-interfaces.

C++ has a much more flexible OOP model. It is just unfortunate that most of it is written off as confusing, evil and/or dangerous.

I used to think C++ had an ugly object model. Then I sat through the C++ FAQ and realised that Multiple inheritance isn't neccessarily evil, nor most of the so-called evil C++ bloat.

And now, we have prototype-oriented object models. No classes, just objects. I'm still trying to wrap my head around it, but I have this intuitive feeling that it isn't so bad.

Re:some postings here scare me

[Anonymous Coward]

Here's what's going to happen. While all this bickering is going on, an established desktop environment (like KDE) is going to just keep advancing and being refined. Then one day everybody's going to wake up and find that the "quiet" environment has taken over and is just dandy.

Sort of like what happened with Linux v. Hurd.

But that won't stop anybody from wallowing in the delights of debating current failures and upcoming vaporware...

Re:some postings here scare me

[master_p]

Longhorn will be 100%. What will Linux have at that time to counter it?

And what makes you thing that an 100% managed O/S is needed ? part of the Linux beauty is that I can use old computers with it. The truth is, the moment Windows becomes 100% managed, I will be using Linux 100%. I don't want managed code, I don't need manage code, it is a stupid idea to run static apps that never change in managed code, just because the developers were too lazy to think for 5 minutes about when to delete an object.

Re:some postings here scare me

[kbradl1]

.Net is a big memory hog too. I would love to see Longohrn as 100% .net because it would require 1 GB of ram just to run IE. Add Outlook, Word and WMP and your brand new-latest-greatest machine would run at a crawl. Then all those people with old machines would have no choice but Linux.

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

[m1chael]

"if it sucks, we should make our own"

What happens if 'our' one sucks?

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.

Re:XAML or ????

[Taladar]

DHTML, IE specific JavaScript hacks. MS offers a "new way to make web pages",... Which might explain why most corporate webpages suck. I don't know about you but I prefer my webpages plain, simple and usable on every browser. All that drop-down-menu,etc. crap just makes the sites slower to navigate.

What about KDE and Python?

[Cronopios]

The original article doesn't even mention the KDE framework.

The KDE project shows that, with the Qt libraries, wise and proper use of C++ can make wonders.

Python is discarted without any discussion. Yet there are Qt and KDE python bindings, which could lead to very effective GUI programming with a very high level language and a clear syntax.

Re:What about KDE and Python?

[Anonymous Coward]

The KDE project shows that, with the Qt libraries, wise and proper use of C++ can make wonders.

Right, that's why it takes five seconds just to open my Home directory. Hooray for poor C++ programming in KDE.

I have to post this anonymously because KDE-heads will mod me down for my opinion, which is crap.

Re:Havoc?

[Anonymous Coward]

Yes, I have heard any and all jokes you can think of about this.

Is he related to Chad Pennington (Jets QB for those that don't know)?

That's one he probrably hasn't heard.

Re:Too bad GNOME's architecture sucks...

[0x0d0a]

From what I've heard, the architechture of GNOME truly sucks.

Ah. According to Penny Arcade, the CEO of Infineon Systems can't have an orgasm unless he kills a dog -- apparently, Tycho heard it on the Internet somewhere.

Hear, Hear!

[ultrabot]

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

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

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

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

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

Re:Hear, Hear!

[Anonymous Coward]

So far the sentiment in Sun regarding C# in GNOME is "ugh". If it becomes a core requirement to compile GNOME, then Mono might be included, but if anything can be done to prevent it gracefully (like recoding C# modules in Java as alternative versions) it will be done.

While Sun has a lot of developer investment in GNOME and JDS, they do not have the wealth of additional resources required to throw at forking GNOME and probably would not want to suffer the community's wrath at such an option. If a fork were created externally that had community support, then perhaps Sun would investigate developing with that project, but face it, the community simply doesn't trust Sun and any kind of fork would immediately be seen as evil.

Re:Hear, Hear!

[Anonymous Coward]

Shit, you're right. I think we all forgot about that Microsoft employee who contributed code to 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).

Because there are benefits to C#/Java.

[Inoshiro]

Like a truly good object hierarchy (everything derives from a base class). Or the fact that memory management is automatic, which is a lot more beneficial. I hate how Mozilla is killed by the Linux kernel after I leave it open for a few weeks because of the persistent, slow memory leaks it has. If it were in C# or Java, it'd be very easy to find the problem and correct it.

Re:Because there are benefits to C#/Java.

[zhenlin]

Even with garbage collection, leaks are possible.

All you have to do is to add an object to some statically-scoped container (list, array, dictionary etc.) and forget to remove it when you're done.

Debugging leaks in garbage collected systems can be very difficult. Similiar leaks can happen in non-GCed systems though, and they're equally hard to find.

Re:Because there are benefits to C#/Java.

[WARM3CH]

a truly good object hierarchy(everything derives from a base class)

Not everybody would like it in all situation. It can help, and it can not. Depends on the situtaions.

In ADA

[Anonymous Coward]

ISO standard, Object Oriented, C interfase, programmed GC.

+5 Insightful

[0x0d0a]

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

Yup.

Java/C# are snazzy for:

* Custom application development

* Lightweight distributed and networked systems.

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

* Vertical market software development.

C/C+ are snazzy for:

* Libraries

* Horizontal market applications

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

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

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

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

Re:+5 Insightful

[Anonymous Coward]

Word is beign rewritten (think port the runtime to OS X) because currently its a huge pile of wrapped APIs to facilitate OS X AND Windows. What do you think makes more business sense, yes, use C# or C++ managed exteneions even with mixed mode until its all done. VS.net, again C++ managed exteneions and C#, IE, yup, it will be mangaged, SQL, its supporting C# and so on. What was your point, o wait I think you had no point.

Re:+5 Insightful

[Felonious Ham]

Your comment is spot on, but I'd suggest that Java for building usuable desktop apps is not as unrealistic as it once was, considering the advent of SWT . At least on Windows, SWT desktop apps run like native, though they still have the liability of larger footprint (and a correspondingly longer startup time).

KDE vs Gnome, C/C++/C#/Java - considered ramblings

[DFJA]

OK, I'm opening myself up to be flamebaited here, but........

In my opinion, KDE is better than Gnome, for two reasons. Firstly, KDE is an older product that has had longer to mature. Secondly and more importantly, it is based on QT which is licensed under the GPL whereas GTK+ is licensed under the LGPL.

Sure, I understand that in the early days QT had licensing problems, and for this reason it was absolutely the correct thing for Gnome (and GTK+) to be brought into existence. However those licensing issue were resolved a long time ago when QT was licenced under the GPL.

This leads me to two questions:

1. Given that we have a very good desktop environment written in C++, is it worth the effort porting this (or any other desktop environment) to another language (Jave, C# etc.), given that it has already reached a high level of stability and maturity? Are we not just reinventing the wheel because we can?

2. I've read about proprietary companies preferring GTK+ to QT because it's licenced under the LGPL, which allows it to be linked to proprietary code. Is this really a good thing? Surely for software to be truly free, we need to discourage proprietary code, full stop. I therefore have my doubts about the LGPL and its suitability in the FOSS world. It can never be more than a stopgap measure, and I think it might actually be counterproductive - if anyone has strong views on this I'm willing to listen.

Seriously, these licencing issues really do concern me. I think if we don't get it right now, we are setting ourselves up for failure in the future when some predatory proprietary company manages to get a crackpot judgement in a crackpot court that undermines the GPL (or the LGPL). Microsoft have already succeeded in the Netherlands and Sweden against Lindows.com, and with patents coming to the forefront might get other spurious legal judgements - they are simply shopping around for a court that doesn't really understand the issues. They might be able to do the same with Mono/.NET, and that would be a disaster for the FOSS community if we don't get our choice of licence correct.

Fork, fork, fork!!!

[Nygard]

The social pressure agaist forking a project is significant, and generally beneficial. In this case, however, forking GNOME to try all of the approaches could be exactly the right thing to do.

Consider this: each of these languages has a "cheerleader" who claims it is the most productive, fastest, most secure, etc. Evaluating these claims objectively is extremely difficult.

But, if GNOME were to fork, we would surely see that one of the forks would produce software faster than the others. If we assume that producing software is equivalent to delivering value to the users, then that fork will be delivering value faster than the others. It will win.

This is truly taking an evolutionary approach. Trying out multiple strategies, allowing them to compete, and then--most importantly--killing off the failed competitors is the essence of evolutionary theory.

As an added benefit, it would provide an amazing real-world laboratory to examine the claims of those who back Java, Mono, C#, etc.

(Naturally, this assumes roughly equal distribution of development talent and project management talent across the forks. That may be the least probably outcome.)

Re:Fork, fork, fork!!!

[ratfynk]

New programming language anouncement!

In Redmond Washington, Bill Gates, the founder of Microsoft, has presented the specs and API for a new all in one computer language. He said "There is no reason why programmers of the future should be forced into a shell. The ability to fork and close your binary will now be made easy, for the first time."

The name of the new language is very revealing to OpenSource coders, It is FORKU

Python

[Khelder]

I am a big python fan. I especially love how well it integrates with Java in Jython. It's great for small programs and as a wrapper to glue together other stuff. I also like jython a lot for debugging Java programs.

However, I don't think it's suitable for large projects because it's not statically typed. (BTW, it's "lose", not "loose".)

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!

Tests are good, but testing is no substitute for static checking; in any large (or probably even medium-sized) project, you're lucky if you can create a code suite that causes every line of code to be executed even once, and forget about a suite that'll test a non-trivial number of paths through the code. I think the performance is a non-issue.

pychecker can spot many static errors.

Thanks for mentioning pychecker; I didn't know about it before. From reading the feature list, it sounds really helpful and I'll definitely use it for future Python projects. However, static typing gives you all that and more.

There is much less need for ugly work arounds from limitations of the type system, so less errors in the first place.

I'm not familiar with C#, but I agree that the Java typesystem does require ugliness sometimes. Generics reduce that a lot, though. And I still believe that the benefits of static type checking far outweigh the occassional hassles of doing ugly casts.

Re:Python

[jamesmrankinjr]

Tests are good, but testing is no substitute for static checking;

Static checking is no substitute for testing. If the tradeoff is more and better tests versus static checking by the compiler, it's a good tradeoff. True, testing probably won't exercise every line of code, but static checking doesn't exercise ANY code. The user of your app won't care one whit that the program compiled without errors if it doesn't do what she wants.

Best,
-jimbo

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.

Re:Python

[Anonymous Coward]

Static checking is no substitute for testing.

He didn't say it was. Even ignoring the whole issue of runtime stability, static checking allows you to have compile-time API contract guarantees.

Re:Python

[Khelder]

If I implied that tests weren't useful or necessary, I take it back. That's not what I meant.

However, I still claim that it's useful to get help from the computer in writing your program correctly in the first place, and static typing helps you do that.

Static typing is also useful because it is a form of documentation that the computer can actually check is correct. You may not make typing mistakes much, and I think probably most people don't on their own code. But if you're trying to understand someone else's code, it's a lot easier to figure out what variable foo is for and what it can do if you know its type. And if you have code that you wrote a long time ago, it's effectively somebody else's code.

What's the down side of static typing? I've seen two main arguments against it here:

1. It's extra work
2. It requires you to do ugly typecasting

The way I think about #1 is as a readability vs. writability issue. Yes, static typing makes code harder/take longer to write, which is a big reason I prefer Python for really short things. However, most lines of code are read *many* more times than they are written---and certainly this applies to the programs that this article talks about. So I think readability should be heavily emphasized. And static typing makes programs more readable.

I think #2 is sometimes a valid complaint. In a statically-typed language, sometimes you have to do ugly casts. However, if you didn't have static typing, you'd be doing the same operation but with no documentation that any type changes were occurring.

Re:Python

[Anonymous Coward]

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.

I did. It looks awfully like what OCaml uses for its class system: the "type" of an object is the sum of the types of its methods, and for any object you can substitute another object of an unrelated class if it has methods taking the same parameters and returning a value of the same type.

OCaml, in case you don't know, is statically typed.

Don't mistake Java's type system for the only kind of static typing. Java's type system is antiquated - it doesn't even infer the simplest types. Try a modern statically typed language, one with type inference, and you'll realise that static type safety doesn't have to mean any hassle at all.

Re:Python

[chromatic]

I'd prefer to say that a static, weakly typed system requires you to do typecasting. That's my gripe with C's type system (as well as that of C++ and Java).

If it worked well, I'd be fine with it. I don't find it to work well, thus I don't care for static typing as done in these languages. (I don't care to do extra work to tell the compiler what it's capable of figuring out on it its own.)

Now a nice type inferencing system, that'd be worth using.

Eeek...Smalltalk and Frameworks.

[Anonymous Coward]

"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 that were true, programmers would be using languages like Smalltalk, and not shying away from Frameworks. A lot of reason developers use not what's best for the job, but inertia of what they know. Just look at the difficulty Apple had when it released Mac OS X, getting "classic" programmers to use Objective-C, and Cocoa.

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

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

[TheRealFoxFire]

Parrot is an unproven VM. It makes some rather odd design decisions, such as using a register based design which they claim is for efficiency, but actually increases complexity with little expense since presumably you'll JIT to a native instruction set anyway and thus have to re-register allocate after you've destroyed all kinds of dependency information by register allocating the first time.

At the very least Parrot needs time to mature before its clear whether its a good target VM. And before its mature, creating languages on top of it will be like building a house on a moving fault line, so we're talking a lot of time before a strong high level language with a complete standard library can be made on Parrot.

In the meantime, the JVM is almost ten years old, and literally dozens of languages compile to it.

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

[JimDabell]

Havoc says nothing about why he thinks the Parrot will not be the right thing

The bit you quoted doesn't say that he thinks Parrot will not be the right thing, it says that he thinks that Perl, Python and Ruby are not the right thing. Perhaps there is the possibility of compiling C# programs to the Parrot VM.

Are there inherent structural flaws in these languages or the Parrot?

The impression I get is that the slow startup time is responsible for these languages not being favoured for desktop applications. Look how much grief the KDE developers got from their users when they were having trouble with the slow startup times due to C++ problems.

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

[cpeterso]

Parrot = vapor

Learn more C++ folks !!!

[Anonymous Coward]

> Coding efficiency. High-level languages are
> simply technically superior to C/C++ for most > uses, desktop applications in particular.

Those who claim that do not know enough C++.

Using Boost or Loki smartpointers, C# or Java lose all the advantages they have over C++ in terms of productivity.
And properly usage of STL (including algorithms)
and templatization make C++ the most productive
language over there for non trivial projects.

One must not look at the effort needed to write
a program that do some trivial work multiply with 1000 and decide how much it take for a big project.

Take your time and learn more C++ before decide to use C# or Java.

Re:Learn more C++ folks !!!

[abigor]

Yes! Loki! What an amazing thing.

Let's not forget other C++ niceties, which are so basic we take them for granted: const correctness and references.

Smartpointers are like localised garbage collectors.

I don't think C++ obviates the need for managed code (on the server, Java rules) but C++ has many things going for it on the client, at least for the time being.

Re:A GNOME Developer speaks. Cut&Paste from OS

[iwbcman]

how's it going oGalaxy...... your really should make a book about this....

Perl Tk

[shadowpuppy]

I may be in the stone ages but I've been playing with Perl's Tk library a bit lately. Every thing goes together like a dream. And at least for Linux to Windows, portability is trivial. My current project works on bith with no changes. I'll probably make an appearence change. But thats trivial.

Re:Perl Tk

[Anonymous Coward]

Why not wxPerl? You will get a GUI that takes on the look and feel of the desktop it runs on in lieu of looking out of place.

Java is probably fast enough already

[DimGeo]

At work, I have a P4 at 2.4 ghz, 512 mb RAM, 1024 mb swap partition for Linux, GeForce 4 Ti 4200, Original NVidia drivers for Linux, Mandrake 10 C.Edition, Sun JDK 1.4.2_03 for Linux, Windows 2000, Sun JDK 1.4.2_03 for Windows.

I found that native KDE apps render _much_ slower than ProSyst's Java IDE - mBedded Builder, written entirely in Java, using AWT (PGUI - ProsystGUI on top of AWT). Also, Eclipse seemed slower (with its native GUI), not to mention KDevelop.

On Windows 2000, however, the mBB is still visually slow, espacially when compared to native apps and Eclipse.

So, I think, for Linux/X at least, Java _is_ fast enough already!

If you combine that with a plugin-in system like OSGI (IBM will be using OSGI in the next generation of Eclipse, I heard rumors) that allows for dynamic updates of portions of the code (bundles), you get the idea.

Go, JIT Languages!

BTW, JIT Langs are faster at times - the code is compiled at runtime and can thus be optimized for whatever hardware you are using - and complied code is discarded at exit (or saved for later runs, I heard rumors that JDK 1.5 will be doing exactly that)

If the JVM and the major libs are loaded only at startup (hint : OSGI), then Java becomes good for the desktop - almost zero startup time, fluent painting (like a crazy 100+ frames per sec game), etc - slick and cool.

Just make sure you deal with the ghasty mem leaks of AWT first - sometimes the GC seems unable to clean AWT objects once they are created, because AWT keeps them in some threads for who knows what.

Re:Java is probably fast enough already

[Trejkaz]

Eclipse does feel slower than a Swing-based IDE like IDEA or native-based IDE like KDevelop. I'm not sure whether you can blame this on Eclipse being written poorly or SWT-Gtk from being written poorly, but it's definitely a real problem.

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.

Re:Dump X11

[mrnick]

Well, at least you think so... This was modded down as redundant. I wish people would at least post a response if they are going to mod a post. Slashdot should make that a requirement in fact.

Nick Powers

Java native integration

[Latent Heat]

I have tried native integration in both Java and CLR, and I argue that each has their merits.

CLR on the surface may be more "seemless", but a lot of it depends on decorating C# function prototypes of attribute information, which is documented in Microsoft circular-hyper-link fashion (each doc entry is "go link to here" which tells you "go link to there" and you end up where you started without learning anything). If the attributes don't do what you want you can go nuts.

Java JNI on the surface is a lot more wordy and clunky, but you program the interface by writing code rather than depend on some square-bracket attributes to do the automagic thing. There is a lot you have to read to get it to work, but SUN has a document that explains the whole thing with chapter, paragraph, and verse rather than hyper link Hell. Yeah, it would be nice if you didn't have to write some much code, especially on the C/C++ side, but it does the job, and since you are writing code to control it, it seems it is more programmable.

I have taken to liking the JNI that much (I am more a Delphi/C++ programmer and am just starting on Java) that I was thinking of migrating apps salami style (one cut at a time) by implementing all the non-GUI parts in Java and calling those parts from a slimmed-down native GUI part -- I might port the native GUI part to different OS's or might eventually port that to Java when I get a handle on Java GUI stuff.

But guess what, I would be taking a functioning Windows app and turn it into something that requires the JVM, and it would have been nicer in an Alternate Universe where the JVM came with Windows (heck, it would be nice if the CLR came with Windows instead of requiring an install).

Anyway, people think of program written in Java calling some low level GUI natives (like with SWT). My thinking is to write the GUI parts native but put the "business logic" in Java -- the JNI goes in both directions and lets you do that. Of course SUN's idea is Java Everywhere for Every Stupid Last Thing, while MS's idea is Java, huh?

Re:Java native integration

[Hard_Code]

Interesting. It was my impression that CLR allowed two-way interoperability with much less explicit coding on the native side to address CLR objects. In JNI you have to use specific APIs to create and refer to objects, ensure they are destroyed and dereferenced, or you get completely screwed over by the garbage collector and/or threading. I thought CLR "did this for you". Also, there is significant overhead in calling out from the Java VM to begin with, whereas I also though CLR, since by policy it is precompiled, doesn't incur that much of an overhead. Informative post anyway, thanks.

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.

Components in C#

[Anonymous Coward]

Does the mono/C# model comply with the Corba CCM module ... or is it something all together for component based development ... I am personally worried that adopting mono's component model could force us away from more friendly component model standards like those from the OMG ...

Could choosing mono couple development tools and methodoligies away from those of microsof ... if there is indeed a conflict here ?

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.

Re:XAML: hierarchical storage of application data

[jamesmrankinjr]

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.

I have utterly no idea what of this means. Can you (or someone else more clueful than I) explain it again in a manner assuming less cluefulness on the part of the reader?

Thanks,
-jimbo

Re:XAML: hierarchical storage of application data

[leandrod]

> Can you (or someone else more clueful than I) explain it again in a manner assuming less cluefulness on the part of the reader?

I really haven't the time. About data I'd point you to some reading materials: the books mentioned on The Third Manifesto, DBDebunk, some articles at DMoz and an implementation with documentation; about OSs, the GNU Hurd site seems to be unreachable now.

Choices versus productivity

[parvenu74]

Language choices can be good, I suppose, until you get into psuedo-religious arguments about which is better, which is superior, which is more pure for your platform, etc.

"nonmaskable" makes a great point about developer productivity with Java/C#; the only thing he leaves out is that if Mono really takes off on linux then you'll have a considerable number of very talented VB.NET programmers being able to cross over to linux for the first time as well. Add to this mix a good RAD tool or the ability to target Mono from VisualStudio.NET and now desktop linux is suddenly a viable option for every small business who relies on some sort of customized app produced by their in-house .NET programmers.

Linux won't be broadly accepted on the desktop until you have the apps to go on it; you won't have the apps until you can quickly and easily build or move all of the line-of-business applications built with "toy languages" like VB/VB.NET to linux. Said apps may not be pretty, elegant, or even efficient, but they get the job done and that is what the suits & the MBA's upstairs want to see: results in as little time as possible.

Re:Choices versus productivity

[Anonymous Coward]

I don't care about pleasing MBAs upstairs. Why does humanity persist in recreating feudal social structures? MBAs are modern "nobility", JUST STOP OBEYING THEIR CLUELESS DEMANDS.

Re:Choices versus productivity

[parvenu74]

Whatever. If that's your attitude you forfeit the right to bitch and whine about not having a job when you refuse to do what your employer lets you go for not doing what they ask of you.

Re:Choices versus productivity

[Anonymous Coward]

I don't bitch and whine about not having a job, actually, anymore than I would bitch about missing out on the three square meals a day that I'd get if I were a slave.

Why is Java no good for Linux?

[wizardmax]

Would someone please explain to me why Sun Java VM can not be included in a Linux distro? Is because you can't modify it for commercial use? Then what is wrong with putting it in as it is? Why exactly do we need an OSS version of Java if the JCP is in charge of changes in Java? I think that its good that there is only one variation of the Java VM/language. Isn't that what we want in a platform, stability?

Re:Why is Java no good for Linux?

[Anonymous Coward]

Licensing. It can't be distributed legally. Even if OSS was excempt from the license, no one wants to build the future of Linux on something that Sun controls lock stock and barrel. If Java is to play a role in the future of Linux, it needs to become just another Open Source piece in the huge puzzle that is a distro, and Sun doesn't like that. Java is not special, it's just another package, it won't be used as a platform, Linux is the platform and Java is the one that needs to conform if it wants to come play.

What has the stability of Java brought us? Crappy GUI toolkits and an API that still shows artifacts from Java 1.0. Stability is overrated. The language has to evolve, and Open Sourcing it will speed up this evolution. .net certainly it evolving, .net 4.0 will probably approach a general purpose VM that you can run any language on, Java as a single language and ideology simply won't be able to keep up at its currrent pace. Java, the package, not the platform, on Linux will not come with a GUI. The apps will be KDE or GNOME apps, which happen to be written in Java. They won't be crossplatform either. If anyone can drag Java down from its high horse, it's IBM. If they opensource their JVM, Java on Linux will take off.

End Rant :)

Re:Why is Java no good for Linux?

[wizardmax]

Why exactly can't sun JVM be attached to Linux? Also, if Sun VM gets OSS'ed what will keep Java standard? What will stop it from forking in 20 ways?

One word... Smalltalk...The shape of tomorrow.

[Anonymous Coward]

Yes, I've seen it. I've thought of taking the Squeak VM and getting it to run with Darwin(1). Combine that with the work done on Evas, X, GNUStep, and things could get interesting. Objects, Frameworks and Language Bindings are the way to go. Apple lead the way with things like Cocoa, we should follow.

(1) Imagine doing virtually all one's programming this way. Gui to drivers, and software installation with the ease of a click (people who've installed software on Sqeak know what I'm talking about). Interface Builder, and Project Builder for Linux, Woo, Hoo.

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.

Re:Question on C# vs. Java

[TheRealFoxFire]

You'd have to compile Java to the CLR, since the CLR has a few properties that the JVM doesn't, like tail recursion optimization. There may be properties the JVM has which aren't supported by the CLR as well which prevent that.

Re:Question on C# vs. Java

[Majix]

The problem is, there is no (decent) open Java VM, nor would I count on Sun opening theirs any time soon. On the other hand, Mono is evolving very fast. .Net too is evolving, IMO it's not hard to see that a few major revisions down the line the .net VM will be a general purpose VM supporting many more programming languages and ideas. In this context, I feel that compiling Java code to Mono bytecode makes a lot more sense than the reverse.

The problem with Mono right now is that part of the .net libraries are patented. If we could just move the Classpath OpenSource Java libraries lock stock and barrel to Mono, get Java support close to 100%, we could use them for the base of the Linux desktop platform without patent liability. And hey, we get full support for C# and the limited support for .net libraries and Linux specific .net extensions such as GTK# thrown in as a bonus. In time, as the VM evolves, more languages like Python and Perl can be supported.

Yes, I know it's possible to compile some other languages to Java bytecode, but the difference IMO is that .net is actively moving towards a general purpose VM while the JCP is not taking this route. In short, Mono has got the VM, Java has got the platform and Open Source can marry the two.

Re:Question on C# vs. Java

[Hard_Code]

"are their insurmountable technical barriers that would prevent compiling both Java and C# to the same bytecode"

No. IKVM for Mono/CLR compiles Java to CLR bytecode. I believe they even had the Java Eclipse IDE running on Mono.

Re:Question on C# vs. Java

[bizcoach]

are there insurmountable technical barriers that would prevent compiling both Java and C# to the same bytecode?

No there aren't. DotGNU Portable.NET has a Java compiler front-end to the cscc compiler which you normally use to compile C# to IL. This Java compiler isn't currently useful (you'll need to port at least the basic class library before you can really use it) and not going forward (because the programmer who worked on it while still a student now has a job that keeps him pretty busy) but it's certainly a good starting point for anyone who wants to work on this.

Also there are no insurmountable technical barriers against the following, more tricky objectives:

• Compiling both Java and C# to JVM bytecode, or to Parrot bytecode.
• Executing both IL and JVM bytecode in the same VM.

These kinds of things aren't currently in active development, but it has been taken into account already during the design of the Portable.NET compiler system and run-time engine that one may eventually want to do such things.

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. :(

The Widget System Should be Changed

[dduardo]

C/C++ is a fine language to program in. There doesn't need to be change in that department. What really needs to change is the way people can interact with widgets. I'm waiting for the day that I can drag any widget from one application to another.

Example: Dragging tabs from Firefox to OpenOffice in oder to have tabbed documents. Or dragging spellcheck from OpenOffice into Firefox.

End users should be able to customize the applications to there needs. Programmers shouldn't have to choose for them.

Re:The Widget System Should be Changed

[damm0]

How do you propose we do this? Applications must have a common protocol with which to share information, and there is no well defined means to do so today.

Sure, there are a hundred different libraries crossed with tens of popular platforms that can let two applications talk. As long as the libraries and platforms involved are the same.

"Managed languages" is one approach to solving this problem. So are "Web Services" and "XML", it just depends on who you ask. We've got hundreds of people proclaiming that they have the true solution, if only everyone would do it their way.

release parties...

[Anonymous Coward]

yea... I bet the girls (read hookers) will be hot there! whoopty!

I will not flame you.

[hummassa]

But your machine is seriously misconfigured.

Examples in question:

1. my personal machine. AthlonXP 1800+ 1GiB RAM, onboard SavagePro video.

I use KDE 3.2.1 (Debian Sid: kernel 2.6.4-rc2-love1) and I have an entire disk (20MiB) with XP installed. KDE feels 4 to 10 times faster than XP Pro. To open a window. To get the Start/K menu. to jump/open a combobox. my Kde desktop is just snappy. the XP desktop is just... not as snappy. My only disadvantage: no 3d accel. Quake is not as fast. hmpf.

2. my wife's machine. Duron 450. 300MiB (approx) RAM. SiS 630.

XP is not an option. *Dog*-slow. like 10-20 seconds to open the start menu. I installed it, she made me remove it ASAP. KDE is quite OK. the sensation of speed is the same as in Win98. 3d accel works (not very well, but does not work very well in 98 either)

conclusion: your X is misconfigured, your kernel has a problem, or something like this.

Re:I will not flame you.

[JianTian13]

Hear, hear.

KDE 3.2.1 (Debian Sid) on my Athlon XP 1700 with 512M RAM is *perceptibly* faster, snappier, whatever than XP with all the "Fischer Price" (<grin>, I like that) eye candy turned *off* on my Athlon XP 2500 w/ 512MB RAM.

It's also worth pointing out that the video on the KDE system is not accelerated: it's an NVidia GF2 without NVidia's drivers setup, while the XP box runs on a 9700 Pro, using the latest Catalyst drivers.

Admittedly, system startup time is a different story, but at least when my KDE desktop comes up, it's actually up -- unlike XP, where the desktop isn't fully functional until several seconds *after* it appears.

I am *sold* on KDE 3.2.1. But that's just my experience. YMMV.

Visual development environment-Classicly trained.

[Anonymous Coward]

"The grandparent will have to wait until software component [wikipedia.org]-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."

Well as any EE will tell you, just having a box of parts will not make you an engineer. Having a box of software parts will make the job of people trained in programming easier, but it will not make someone who's not trained in programming, at best a good programmer, at worst a programmer period. Remember part of the appeal of Linux was that the people were competent, and not under performance pressure to code. That's why we have a world class kernel, not because it's done in "C".

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:HELP THE USER AND NOT THE PROGRAMER

[Anonymous Coward]

I agree..
The ratio is 1 programmer to many users who will use it multiple times. So it is worth it from the global perspective to put more effort in programming so there is less effort in using.

Re:HELP THE USER AND NOT THE PROGRAMER

[Trejkaz]

At least until someone has to change the program and you realise it isn't possible without three years of development. *cough* Windows *cough*

Re:HELP THE USER AND NOT THE PROGRAMER

[Moraelin]

I'm with you.

And I'll add another thing. It never ceases to amaze me how, instead of using the extra CPU power to do more advanced stuff, we just find ways to do the same old things less efficiently. Or with more clueless monkeys instead of programmers.

I was reading that, in the last 30 years, computing speed increased a million times. Roll it around in your head. A MILLION TIMES! 1,000,000.

Do we do 1,000,000 times more with them? Nope. We just added wrappers after wrappers of crap and buzzwords, to waste those cycles.

E.g., a program back then would have just printed the damn data. Nowadays, nah, we'll serialize/desrialize it 10 times through CORBA/EJB/SOAP/whatever, then convert it to XML, parse it right back through a slow and bloated XSLT template on it, to get HTML out, then use a browser to parse the HTML and actually display that data. Buzzword Driven Architecture at its finest.

And, no, I'm _not_ against using those cycles to actually offer something of value for the user. GUIs are good. Extra services, like spell-checking on the fly or auto-completion in an IDE, are great.

But 99% of computing power does not go into those useful things. It goes into allowing unskilled monkeys to throw together a half-arsed program, and be able to add 20 buzzwords to their resume. It goes into layers upon layers of useless (for the user) crap, that just slows everything down.

"There are currently 12 people partying"

[twener]

Now you know how many people worked on the new file selector and the spatial Nautilus.

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

Like Apple ...

[webmilhouse]

Why have only 1 way? Apple provides APIs that can be used for writing programs in Java, objective-c (blech), C++, etc.

However, to get good portability and the largest coder base, it should probably support mono and Java (maybe using SWT).

Re:Like Apple ...

[berkleyidiot]

objective-c has it's weak points and strong points like any other language, but it's certainly better than c++. and for those who think it's ugly or confusing, there is really only one syntactical difference from c - using brackets for method calls ( [obj method]; ). it also has the advantage of being able to mix c [and c++ if gcc gets around to it] code seamlessly since it's a superset of c.

more important is the framework - OpenStep, GNUStep, Cocoa, whatever you want to call it. the foundation is already stable, runs on many platforms (GNUStep runs on the BSDs, linux, windows, even osx), and has a large number of applications that could be easily ported. the backend rendering engine is even interchangable. the specification is open, and the GNUstep project has kept up well with Apple's developments in Cocoa. and like the parent said, it would be easy to add bindings for java/python/whatever (already done in osx).

why not stick with something that has been shown to work? i can only imagine the horror of my desktop looking like a swing app. now *thats* blech.

Why not embedded scripting?-Scripted Objects.

[Anonymous Coward]

What you're going to see more of is an Object Oriented base with a Scripting Language on top. Remember the Amiga discussion yesterday and ARexx?

Common joes were using it to do some impressive things. Seems what's old is new again.

XAML may be more popular than XUL

[Anonymous Coward]

One of the problems with XUL is the installation of the applications (size of installation packages and the work involved), not neccessarily the XUL as language itself.

Microsoft XAML will have this problems resolved: the language support will be available in any Windows Longhorn (or whatever they will call it) machine without complex installation. It will be integrated with C#, applications will load fast, etc, etc.

This is the "integration" that MS often mentions in PR materials. This is important advantage of .NET - not that it is theoretically better, but deploying applications developed on that platform will have in time less and less complications (as .NET will be in more and more machines preinstalled) than for example java.

It is often a problem with "better" technologies and languages than MS's that they are in part better, but they fail to make all parts and situations of their usage easier.

Idiot

[Anonymous Coward]

Exhibit D: I haven't tried any other program in KDE to see if they might be better than the old programs.

Re:Idiot

[Anonymous Coward]

Galeon .... Ephiphany?
Balsa .... Evolution?

etc. etc. etc. There's plenty of rewriting going on in GNOME too...

Re:Idiot

[Anonymous Coward]

Yeah but I'm not interested in Gnome. Personally I see Gnome itself as one huge pointless duplication of effort, done only out of a gruge against the KDE developers. Re-writing in Gnome is just as harmful as it is in KDE, though.

Gnome is definitely slower.

[Colin Smith]

Sorry, the problem *is* with Gnome/GTK. It is *noticably* slower than other toolkits/ UIs/ libraries which don't seem to have a problem with flickering.

Now, I don't know where the performance problems are *within* the glib/gtk/gnome stack, but that *is* where they are.

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:In this way

[Anonymous Coward]

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

As a Windows programmer using C#, I don't want this to happen, either. The less people doing Windows programming, the more $$$ for me.

Re:In this way

[prockcore]

2) Linux programmers find Windows Forms is just easier to use at the moment

This step will never happen. Gtk# is easier, and actually works cross platform.

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.

any NeoDesk programmers working on Linux desktop?

[The Lynxpro]

I just had an epiphany in the form of a question to ask the interested SlashDot community...

Does anyone know if any former NeoDesk programmers and enthusiasts (from the Atari ST era) are presently working on any of the Linux desktop projects?

If not, that would be a shame since that desktop manager was pretty polished for its era...

Release Parties

[Anonymous Coward]

Wow, you know you live in a serious geek area when Party number 2 is about 3 blocks from where you live.

And hand the future of Gnome to Microsoft!

[gwait]

I wonder how much I would have to be paid to
publicly promote .NET to the Linux community?

Can we say lean and mean?

[vlx27]

Ah yes, the never ending quest for new and better ways to bog down the Linux desktop... this time with a new load of resident interpreters. But I guess this shouldn't be a surprise... bloat is well on it's way to becoming a Linux standard.

New lanaguages and concepts are cool and help Linux to grow. New users do too. A lot of people try Linux on older hardware where they've been told it's supposed to work the best. Then it's "welcome to the modern distro" where new installs are frequently in swap before the default Gnome or KDE desktop finishes booting. Watch enthusiasm turn to grief as the new user clicks on OpenOffice or Mozilla... and waits and waits and waits on the same machine that previously ran Win95, IE and MS office just fine.

It would be nice if Linux had the clout to inspire people to upgrade their hardware like Microsoft does with every new version... but we don't. If we want carve out a beachhead for Linux on the desktop, we'll to make it run well out of the box on the older hardware that people are willing to try it on.

A group of us recently talked a local school into recycling some of their old P-III, 128 mb systems to Linux instead of scrapping them. It took a LOT of effort to unravel the bloat, provide a nice desktop and get the boxes to run Mozilla and OpenOffice without swapping. Requiring any kind of resident interpreter to support the basic desktop would have made this success story impossible.

Techie trends and toys are great. But if desktop developers don't factor in the end user experience, they'll be creating a lot of code that nobody will have the time or patience to want.

Please, guys... use efficient compiled languages for basic operating system components!

The future of the Linux desktop:

[Anonymous Coward]

Check it out, right here!

Nice article but...

[akuzi]

Is ease of development really holding back Gnome?

The underlying assumption of the blog seems to be that you need to write apps in Java or C#/Mono to compete with Microsoft on the desktop in the future...

This is just is not true - look at OS X, most of Apple's apps are written in Obj-C which is just C with a few OO extensions.

Most developers like to think about low-level technologies but in the end it's usability and what apps are available (not what they're written in) that really count.

Re:Nice article but...

[lieven_dekeyser]

Interface Builder/Obj-C/Cocoa is actually very much like Java/.NET it's the Cocoa class library that helps Apple move faster than a few years ago, not the +/-5 syntax rules that Obj-C adds to C to make it object oriented

checked the site...

[Cynikal]

"There are currently 17 people partying in 8 different parties"

hmm 2.125 people per party... higher turnout than i expected

Avoiding the question

[Anonymous Coward]

I feel the same way. Four years ago, I began playing around with Linux because it was FREE and OPEN. I quickly gravitated to Gnome over KDE because it was MODULAR and LIGHTWEIGHT, not to mention UNENCUMBERED.

I've noticed that in recent threads (since Miguel's pronouncement last week) NOBODY has answered your question. It's all smoke and mirrors - FUD and excuses - with a little RMS bashing sprinkled in. This includes, apparently, the comments from some of Gnome's core developers.

The impression I'm getting is that they either 1) see their long-term goal as creating a mass-market-friendly desktop environment for Linux, without regard to whether it remains FREE or OPEN, 2) don't really have any long-term plan for the codebase, and so don't care whether it all goes down the tubes in another year or two (whenever MS decides to pull their bricks out of the foundation), or 3) they have a plan and a vision, but are making every effort to hide it from the F/OSS community.

I, for one, say "see ya later" to our new backdoor-overlords. After reading the 6 replies to your question posted so far, I am now convinced that it's time to start looking for replacement applications to all my gtk+/gnome favorites.

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.

Why Smalltalk/Python/C really are dead.

[110010001000]

There is relatively little use of languages like Smalltalk because there are relatively few existing components and frameworks available for it. Yes, you could probably rig something up for Smalltalk/Eiffel/Python/wtf else - but this stuff exists today for C# and Java.

I think that with C# and .NET Microsoft will dominate. Coding application leveland even system level apps in C without a stable technology and framework isn't going to cut it anymore - the end user and system interoperability requirements are getting too complex. .NET exists and provides rich functionality on all versions of Windows, from cell phones to servers. Java also provides this apparently, but in my opinion Java will lose out because Sun doesn't have complete control over Java on all the platforms, while MS does over .NET. It is important that there is one maintainer of the framework and that the maintainer of the framework also controls the underlying system (the OS). I am sure there are a lot of people who would be outraged at this, but this is the only way to provide a stable platform to develop on currently.

C/C++/Python/Eiffel/Ruby/wtf else is dying, already dead to me actually. The only thing that keeps it alive is the need for maintanace and developer inertia. Those programmers will quickly find themselves left behind and unemployable if they are not willing to embrace the new shift toward managed languages and frameworks.

For new application development there are only two real choices currently: Java and a .NET language. This comes from a guy who has been programming professionally with C and C++ for most of his career!

Bizarre thing about KDE and GNOME

[bonch]

If you mention the strange slowness, people will blame X. But then you ask around, and "experts" tell you X is just fine, and that it's the poor window managers. Talk to the window manager guys and they blame the library guys. Someone else is always to blame, and if you complain, they blame you for not "sending a patch."

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

OOo UNO allows multiple languages to control UI

[DickBreath]

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

UNO in OpenOffice.org does this and more.

As a serious OOo scripter, I have been able to script OOo in a variety of languages using OOo's UNO API. Furthermore, you can write new components in any implementation language, and your components' interfaces are available immediately to any other implementation language. If you write a service with a set of interfaces, I can call the methods in your interfaces, and I might not even know what language you wrote your service in.

On Windows, OpenOffice.org has a UNO to COM/OLE bridge. So from, for instance, Visual Basic, you can manipulate OpenOffice.org. (Or using any other Windows Automation language.)

It is also completely platform neutral. I have personally had a java program running on one computer controlling OOo on another computer. The two don't even have to be on the same OS.

Having an entire desktop environment scriptable via. UNO would be my dream come true.

Right, while KDE...

[bonch]

...right, while KDE recreates the Windows mistakes of taskbars, endless sidebars, too many buttons, a start menu full of redundancies (Control Center, Preferences, System, etc.), "More Programs" subgroups for absolutely no good reason, and a monstrous Control Center.

I think GNOME and KDE both have a long way to go before they can even be considered in the same league as Windows 95. Sorry, it's how I feel.

My god, GNOME has a registry. It's just another way of storing config information. As if KDE doens't store the same kind of info simply in different ways.

Can't find the patch.

[Anonymous Coward]

You're working on old information. The Clue patch was killed by Colonel Mustard in the Pantry with a candlestick.

Open Source cannot have a unified managed platform

[damm0]

Open source excels at providing excellent commodity software. Microsoft claims that Open Source doesn't innovate, and when it comes to providing a well-financed unified vision, they are 100% correct.

However, open source does not need and cannot provide a single managed platform. A de-facto standard might emerge, but only after several generations of managed platform technology and only once managed platforms are already embedded in everyday computing.

In the meantime, keep on using the best tools.

Spacial navigation

[bonch]

It's called spacial navigation. It's the reason Apple's older versions of Finder were so beloved. You weren't using a "browser" that listed the contents of the directories on your computer. When you opened a folder, it popped open its own window with no toolbar. Users treated it like they were actually looking at the folder itself. The same thing with icons--they considered them not representations of their files but the files themselves. It's a more human and logical way of dealing with interacting with a computer.

Microsoft and Linux desktops have people so weened on "browsers" that people have forgotten the intuitiveness of the previous solutions. I handle the tech support within my company. When I'm helping them look for a file, they are COMPLETELY CONFUSED by "Back" buttons and "Move up" buttons when looking through folders. They don't relate to the concept of a browser looking through their filesystem. To them, when you tell them to double-click "Stuff" on their desktop, they're really opening the Stuff folder. I have yet to see them ever use "Back" or "Up" or even the Address bar, because to them the concepts are bizarre and foreign and unnatural.

Do a search for "spacial navigation" sometime. Arstechnica has an excellent article about it, describing a concept of a redesigned OS X Finder.

XAML is NOT a replacement for HTML AFAIK

[melted]

It is merely a language to define application UIs without writing mucho code (thus allowing non-coders to be responsible for UI). Your XAML UI description transparently links with code-behind, and everything is stored inside same assembly. A solution in search of a problem if you ask me, programming UI in .NET Web/Windows Forms is already easy enough, but that's the path they've chosen.

trapping crashes

[MenTaLguY]

That's just a choice of the programmer, though.

Even in C, if you want to you can catch SIGSEGV and silently keep running/attempt some recovery. Free software programmers rightly have some aversion to this, but it's common enough in the commercial world.

What you describe is also a problem for Unix applications that are separated into several processes -- ignore SIGCHLD if something bad happens, and you get the precise same symptoms you describe. I've seen that happen quite a bit in Free Software. If you don't have exceptions, you have to get very religious about checking _every_ return value or you will write bad code.

It's really just about appropriateness of error handling on the part of the programmer. There are some errors that the program absolutely should not try to continue after, and others that don't invalidate the state of the process.

In general exceptions are nicer than crashes because they give you more choices than "UNKNOWN STATE MUST DIE" (SIGSEGV/SIGBUS) and "oh, that didn't work" (an [sadly often unchecked] return value), so it becomes pratical to make things like failure to open a file a slightly "harder" error that can't be silently ignored without explicit effort on the part of the programmer.

Exceptions are also nice in that they can be used to carry descriptive error messages. I wish more programmers took advantage of that.

So, in short, all the problems you describe are due to poor error handling practices on the part of the programmer, and already occur all too frequently in C.

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.

Gnome 3.0

[bonch]

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.

Uh, there's talk of Gnome 3.0 going almost entirely Mono. If you like Mono, what's the problem with Gnome?

I don't get this fear of change that many Linux users have. We have to keep moving forward. Apple and Microsoft are full-steam ahead and we're stuck still writing little transparency extensions for our X servers and trying to get fonts not to suck.

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.

.NET and other languages

[bonch]

I guess you forgot that part of the beauty of .NET, and therefore Mono presumably, is that you don't have to code in C# to take advantage of it. Microsoft has documented this for years. Visual Basic .NET, anyone?

You can have all these run-time binaries coded in various different languages, and it doesn't matter to the virtual machine. It couldn't care less.

Re:.NET and other languages

[Ben Hutchings]

You can have any language you want, just so long as you don't want multiple inheritance of implementation - which C++, Perl, Python and Ruby all support. (Actually you can, but not in managed code.)

Rubbish

[Anonymous Coward]

This is probably a troll - but I can't resist:

Python is much faster, both starting and running, and seems to use less resources.

What are you smoking?! In this benchmark Java was 7 times faster than Python, and that was the 1.4 JVM, 1.5 is even better.

Python programs seem less prone to runtime errors (NullPointerException), and are generally more solid.

So you are claiming that a loosely typed language is less prone to runtime errors than a strictly typed language. Uh huh, right.

Python is much quicker to write, easier to understand and easier to debug

That is a completely subjective statement. I have used both Java and Python extensively, and for non toy applications, I find Java much faster, particularly when using Eclipse.

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!

Rubbish, Eclipse compiles Java as you type it (with no noticable overhead).

Re:Rubbish

[tal197]

Python is much faster, both starting and running, and seems to use less resources.

What are you smoking?! In this benchmark Java was 7 times faster than Python, and that was the 1.4 JVM, 1.5 is even better.

OK, I only read the start of the article you referenced. From the first paragraph Unfortunately, the trigonometry performance of Java 1.4.2 can only be described as dismal. It was bafflingly bad--worse even than fully interpreted Python!.

However, that's not important. We're talking about desktop applications here, not math-intensive stuff. Python is fast because it off-loads critical sections into C libraries (using map(), etc). If you compare low-level Python with Java (ie, code that doesn't use library functions), Java will win.

But, outside of Java-benchmarks, little code is actually like this. In practice (which is what people care about), Python is usually much faster. When I start a Python application, it usually appears instantly. Java apps usually take two or three seconds just to open a window, and perform just as sluggishly when running.

not accelerated?

[hummassa]

Even XFree's nvidia drivers are 2d-accelerated... unless you're using vesafb or something...

OpenOffice.org

[Bill, Shooter of Bul]

I haven't found a computer running ANY operating system on ANY hardware that runs OpenOffice at an acceptable speed.

Re:OpenOffice.org

[An Onerous Coward]

Maybe you're stuck in some alternate dimension where a top of the line computer is a P-200 with 64 megs of RAM. Or maybe you're one of those Type A personalities who drums their fingers and complains when a web page takes more than three seconds to load. But for us normal people on our normal computers, spending two or three hours formatting a document in OO means spending an aggregate of three minutes waiting on the computer. The rest of the time, the computer waits on us.

The main "slowness" I notice is in the startup time. On the Athlon 1400 I'm sitting in front of, it takes fifteen seconds to get me from clicking the icon to a functioning cursor. That's about the same as my Celeron 433 at home, so the main bottleneck appears to be loading everything into memory. Close and re-open the app, and it takes about five seconds to get started. Just for comparison, Word took about 7 seconds.

Once OO is up and running, I can't think of any operation that will cause a noticeable slowdown.

I'll admit that fifteen seconds is a lot compared to most computer operations, but since it only happens once per session, it's hard to call it "unacceptable."

Maybe you're thinking of the SunONE IDE. Now there's a piece of software that can remind you how short life really is, and how quickly it slips away.

Re:OpenOffice.org

[Anonymous Coward]

Alternate dimension? Don't be so arrogant. There are MILLIONS of computers out there in businesses and homes with 32 and 64M, all of which could (and maybe should!) be running Linux, but can't because it's just as bloated as Windows. We're losing a huge potential market of convertees here.

Linux's adoption rate would improve immensely if it offered a great upgrade path. If RH, IBM, Sun and co. could go into a company and say: "Don't spend money on hardware upgrades for XP/2k, just install our Linux and save!" then we'd be sorted. But the average box running NT4 or Win98 is nowhere near capable enough to run a modern desktop Linux, so companies have to buy new hardware anyway. And if they're splashing out on new boxes, they may as well stick with Windows for the time being...

People are missing the point

[Sleepy]

I don't think the point is so much "which API", but "which API is going to allow a boatload of new applications developed quickly".

The points are:
1) C development is SLOW.
2) Scripting languages (ANY of them) are (naturally!) slower than C.
3) It's the applications, stupid
4) Microsoft is patenting everything they can, even in cases where prior art exists (XML, ClearType for examples)

#3 trumps #1. SURE, C programs are less bloated and they'll run faster (unless they are the kind of program that just sits there waiting for input)

The end-user does not care about C. They care about availability of featureful applications that run respectably on THEIR computer.

I don't think people here are REALLY worried about slower aplications becoming popular... by definition slow applications are never accepted.

People are elevating the "performance" issue as a mask for what really troubles them. It's ridiculous to talk about 4 way Xeons and gigs of memory to back up issues with non-C development.

Every few years this SAME argument gets taken up, with a new costume. Yes, Mono/Java/Python are slower than C.

FACT. There's also a dearth of programs that people want.

Logically, if folks want to stick to C they can... they'll just have to work harder to get same feature throughput as the guy who adopts interpreted languages. That's evolution. :-)

I suspect GNOME-Core will be continued in C for a very long time (longer than it matters).

One thing I've noticed is, oftentimes the person with the SLOWEST computer IS the techie. They KNOW how software works, and resent being forced to upgrade because software they like now has higher hardware requirements. They are proud of the PC they built, and question why it's no longer targeted by new code. But then they're not willing to accept that the new code allows more work to be done (or otherwise pick up the slack to offer the same pace development in C).

Free/Open software is a democratic model.. don't like what someone did in Mono in just 8 hours.. spend 40 hours and rewrite it in C! Don't begrudge everyone else to wait until your upgrade is driven by hardware failure.

It's the same thing when everyone moved from DOS to Windows, or Console to X11.

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.

Interpreted C++?

[Anonymous Coward]

Um, what language do you think Mozilla and OO.o are written in?

Proof...

[Anonymous Coward]

...if it were ever needed, that some /. moderators don't have a clue about software engineering (yeah, mod me down - the truth hurts).

I am waiting for sfraggle's next comment when he tries to persuade us that we should all be using goto.

Type checking is about more accurately specifying what a function or class does, and affording compile-time guarantees as to what that class will or will-not do.

Re:Proof...

[sfraggle]

I am waiting for sfraggle's next comment when he tries to persuade us that we should all be using goto.

Actually Edsger Dijkstra is one of my heroes :)

Type checking is about more accurately specifying what a function or class does, and affording compile-time guarantees as to what that class will or will-not do.

It seems to me that this creates the kind of "if it compiles, ship it" attitude that leads to so much bad software. A compiler cannot guarantee what your class will or will not do - only proper testing can.

If you're writing code professionally, you should be writing tests, and they make type checks pretty much redundant anyway - so what is the point in type checking?

As for specifying what a function or class does, isnt that the point of documentation? Good documentation will give a much more accurate specification of what something does than "the arguments should be of these types", which is essentially all that type checking gives you.

Re:Proof...

[Anonymous Coward]

A compiler cannot guarantee what your class will or will not do - only proper testing can.

Obviously it can't guarantee everything a class will do, but it can make guarantees such as "This method will return an integer".

If you're writing code professionally, you should be writing tests, and they make type checks pretty much redundant anyway - so what is the point in type checking?

By that argument, what is the point in the compiler doing compile-time syntax checks? It is easier to be told by a compiler that there *is* a problem than to have to hunt for it at runtime.

Linux needs better coding IDEs.

[Adolph_Hitler]

Linux and especially, needs a better way to quickly code desktop applications. I've tried coding in gnome and couldnt mamange to do it because the environment is complete chaos. How can Linux revolutionize the IDE so that rapid application development is possible? Why not set up a P2P system into the IDE so people reuse code?

Re:Linux needs better coding IDEs.

[abradsn]

Kylix. www.borland.com

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

Amen brotha!

[Anonymous Coward]

Having lived on K6-2 with redhat 6.2 for years I recently tried Fedora on a P3 600. Optimization notwithstanding the desktop is awfully slow. I'll stick with gnome 1.0 and gtk-1.2 for now, thanks.

Re:Amen brotha!

[Anonymous Coward]

Me either !!!
I own a celeron 450, 256 meg, all UW scsi and gnome 2.4 on mandrake 9.2 drove me crazy, I downgrade to my mdk 8.0 and gnome 1.4 with enlightenment and life is nicer then.......

A GNOME Developer speaks - c&p from OSNews

[Anonymous Coward]

That's quite an facile editorial but you can't expect better from normal users. My screenshot looks better than yours. Evolution is better than KMail, GNOME looks more polished than KDE and so on. I do use XChat, Abiword, Rhythmbox.... ...usually you get stuff like these from normal users. And this is ok since you can't blame them for stuff they simply don't know about or don't have a slighest knowledge about.

Such editorials are hard to take serious since they are build up on basicly NO deeper knowledge of the matter. Most people I met so far are full of prejudices and seek for excuses or explaination why they prefer the one over the other while in reality they have no slightest clue on what parameters they compare the things.

If people do like the gance ICONS over the functionality then it's quite ok but that's absolutely NO framework to do such comparisons.

I do come from the GNOME architecture and spent the last 5 years on it. I also spent a lot of time (nearly 1 year now if I sum everything up) on KDE 3.x architecture including the latest KDE 3.2 (please note I still do use GNOME and I am up to CVS 2.6 release myself).

Although calling myself a GNOME vetaran I am also not shy to criticise GNOME and I do this in the public as well. Ok I got told from a couple of people if I don't like GNOME that I simply should switch and so on. But these are usually people who have a tunnelview and do not want to see or understand the problems around GNOME.

Speaking as a developer with nearly 23years of programming skills on my back I can tell you that GNOME may look polished on the first view but on the second view it isn't.

Technically GNOME is quite a messy architecture with a lot of unfinished, half polished and half working stuff inside. Given here are examples like broken gnome-vfs, half implementations of things (GStreamer still half implemented into GNOME (if you can call it an implementation at all)) rapid changes of things that make it hard for developers to catch up and a never ending bughunting. While it is questionable if some stuff can simply be fixed with patches while it's more required to publicly talk about the Framework itself.

Sure GNOME will become better but the time developers spent fixing all the stuff is the time that speaks for KDE to really improve it with needed features. We here on GNOME are only walking in the circle but don't have a real progress in true usability (not that farce people talk to one person and then to the next). Real usability here is using the features provided by the architecture that is when I as scientists want to do UML stuff that I seriously find an application written for that framework that can do it. When I eye over to the KDE architecture then as strange it sounds I do find more of these needed tools than I can find on GNOME. This can be continued in many areas where I find more scientific Software to do my work and Software that works reliable and not crash or misbehave or behave unexpected.

Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.

We still have many issues on GNOME which are Framework related. We now got the new Fileselector but yet they still act differently in each app. Some still have the old Fileselector, some the new Fileselector, some appearance of new Fileselectors are differently than in other apps that use the new Fileselector code and so on. When people talk about polish and consistency, then I like to ask what kind of consistency and polish is this ? We still have a couple of different ways to open Window in GNOME.

- GTK-Application-Window,
- BonoboUI Window,
- GnomeUI Window,

Then a lot of stuff inside GNOME are hardcoded UI's, some are using *.glade files (not to mention that GLADE the interface buil

C is easier to learn and code.

[Adolph_Hitler]

There are more code examples for C, C is a more well known language, its generally easier to learn (the syntax)

Until they make much better IDEs for linux that compare to visual basic, or some of Microsofts stuff, I don't want all this new syntax. It's going to take even longer to make programs even if the programs have less bugs.

Why can't we invent and use a new language, thats easier to learn (syntax wise) than C++, or Java, which can compete with C#, and which has the ability to be OO or not depending on how its used.

I don't really like the OO style of programming, soe people don't code in that way, and I also think we need a way to quickly code up the GUI, Glade just doesnt come close to comparing to Visual basic and until it does I don't see how Linux will compete!

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

Re:A Mono developer's perpective

[Anonymous Coward]

How about Novell sponsor som lawyers/patent investigators to investigate the free part of mono (mono compiler/runtime, gtk#, gnome#, the mysql/postgres db access and so on) to see if mono is touching anything encumbered and publish the result on the web?

While i have several years experience with Java and only i few months with C#, I agree that C# can better integrate with C and for that (technical) reason would be a better fit for the gnome project.

I am curious to know if mono became part of official gnome what excactly that would mean? Wouldnt it just be anohther set of language bindings that like the rest is always late and incomplete compared with gtk/gnome/others library releases?? After all the core libraries probably wouldnt be rewritten using c# any time soon.

Answer

[bonch]

Nobody said there would only be one way.

Problem solved.

Longhorn release date

[bonch]

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?

Okay, I'm sick of this. Microsoft never gave a release date for Longhorn. They said they were targetting late 2005. Then, they changed and said they'd like to hit late 2005, but early 2006 looked more possible.

They haven't changed since. But since then, Slashdotters have endlessly called Longhorn "vaporware" and even completely made up years like you just have. 2008? Give me a break.

Like they always have, Microsoft will clearly tell you early 2006 is what they're aiming for. They haven't changed since that first announcement. I don't get the big deal over jumping on them for a target release year. Linux 2.6 came out WAY later than was originally targetted.

and what about code reuse?

[Adolph_Hitler]

Can I find millions of lines of refrence code to tell me exactly how to write any application I want in C#? Until I can, I wont be using C#. Even Java is more mature than C#!

How is it easier to code in say C# than C?

[Adolph_Hitler]

I'd think, that because everything has been done in C already, its easy to find algorithms, find open code to use for your programs, and the tools for C are mature. Why use C#? Give me some reasons, don't say its faster for development, tell me why.

Re:How is it easier to code in say C# than C?

[Trejkaz]

The lack of segfaulting is enough for me to prefer Java or C# over C. Too many applications in, well, almost any other language seem to crash out like that. In either Java or C# all you have to do is catch the exception at whatever point and any errors which might have occurred can be recovered.

Re:How is it easier to code in say C# than C?

[actiondan]

Pretty much all of the good points about using C# are about the common language runtime and JIT compiling rather than the language per se.

Things I like about C# as a language:

* Attributes - being able to add proper meta data to code is really nice if the team designs with it in mind.

* Proper structured error handling

errr...

Other than that, everything that has made me think 'that's nice' has been a feature of the runtime rather than the language.

In fact, the two I listed are really runtime features exposed through the language ;)

Really, though, the language is nothing - if you know c and c++ then c# or Java would take you less than a day to learn (in terms of the language itself) The time is in learning the runtimes and the APIs.

I use C# because of ASP.NET - it is genuinely a great web development API for certain kinds of web application. It actually gets away from 'I'm outputting a stream of HTML' and allows you think at a higher level about what you want your application to do (although it does allow access to the raw stream if you want it) That's what these new languages and runtimes are all about, in my opinion - abstracting away and allowing us to think about what the application does rather than reinventing plumbing code. Not suitable for every task, but great for getting useful applications built.

Dan.

We already decided on C and C++

[Adolph_Hitler]

These are the languages 90% of programmers already know. Why should we all move to C# and Java now, just because people say we should? Why should we go from an experienced C or C++ programmer into a newbie all over again as we learn C# or Java? Now, if we can make a new language with the same exact syntax as C, which is also object oriented, and a lot easier than Java or C++, or even a language as easy as Basic with the portability of Java, like Visual Basic, then yes we'd have the power to do desktop programs faster. But C#? Java? Those languages are harder than the languages we currently use (more syntax), less bug prone, but harder to grasp and almost no one knows them. Why not use Basic? Everyone knows Basic, why do you think Visual Basic is doing so well?

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

HECK NO.

[Anonymous Coward]

Ada is by far the stupidist language you could have possibly named. People who learn Ada are programatically retarded. Its NOT completely Object Oriented. There are hundreds of complaints I could lodge against it, but I simply dont have the time.

Its called ClickNRun Fool!

[Adolph_Hitler]

Click & Run was invented for people like you, people who are too stupid to install their own applications.

Simply buy the LindowsOS, then you'll be able to go to the software warehouse and simply click and run all your software, this install is easier than Windows, easier than MacOSX, easier than any OS before it. You don't even have to install, you just ClickNRun.

If you cant figure this out, perhaps you should go back to playstation, you arent ready for the land of computers yet son.

Re:Its called ClickNRun Fool!

[Anonymous Coward]

"People don't exist to serve systems, systems exist to serve people."

"Click & Run was invented for people like you, people who are too stupid to install their own applications. If you cant figure this out, perhaps you should go back to playstation, you arent ready for the land of computers yet son."

Sense any contradiction here?

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/

Re:D as an example.

[Rick and Roll]

Yeah, I agree with that.

But I also think that Ada would be an excellent language to code a toolkit in. It has good support for OOP, Generics, and Tasking. Plus it's not case-sensitive. I actually like its verbosity. But most people hate it.

I apologize

[Anonymous Coward]

I'm sorry but gnome, kde, etc... has gotten so shitty and so much like win95, I switched back to windowmaker. Come on guys, linux needs a real desktop and one that is original and fast. Windows and apple seem to be capable of having original desktops. Gnome and KDe however just look like copies of mac and windows desktops but worse. Plus gnome is slow as donkey nuts.

--1, Microsoft astroturfing

[ultrabot]

.NET exists and provides rich functionality on all versions of Windows, from cell phones to servers.

Copy-pasted that straight from a MSFT marketing brochure?

Re:--1, Microsoft astroturfing

[110010001000]

Sorry you don't agree, zealot - but it is the truth. Are you familiar with .NET at all? Have you actually seen it running on cell phones and servers? Guess what, I have!

Static type checking is very important for IDEs

[rauhest]

Static type checking allows IDE to
- check syntax on the fly, without requiring you to recompile the application;
- do refactorings (move and rename classes and/or variables updating all references, generate some code automatically, etc);
- help with variables/methods/classes/etc names completion.

Although lack of static typing has many advantages (your points on the matter are very good), it should be noted that a powerful IDE can speed up development enormously. (I'll never switch back to XEmacs from Eclipse to do Java development :))

Python is undoubtedly an excellent language for many applications, including some desktop apps (I developed with python+GTK, and it was really great), but I would still hesitate to use it in really big and complex projects.

Re:Static type checking is very important for IDEs

[chromatic]

I'm not sure that's entirely correct. Have you seen the Smalltalk browser? Somehow, they manage to do those things well enough in a dynamic language.

Re:Static type checking is very important for IDEs

[rauhest]

Unfortunately, I have no Smalltalk experience at all :(

I guess I should take a look at it some day...

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?

Re:Cry Havoc!

[ainsoph]

At least he has the balls to be in the public eye and say flat out MONO is a trap and a stupid direction for anyone involved in Gnome to consider.

Like what idiocy is next? Cloning the Longhorn API?

Seems the only way Linux can survive is play copy cat to all things Redmond.

Or so some Microsoft employee says.

Re:Cry Havoc!

[Brandybuck]

Yes, he has those "balls." Which isn't saying much because most C, C++, Java, Python, Ruby, etc, developers are saying the same thing.

Re:Cry Havoc!

[ainsoph]

For sure// But the more the merrier is what I think needs to happen.

Self Evident

[Anonymous Coward]

This whole thread and the discussion within
pretty much paint the picture of why Linux
will never unseat Windows on the desktop.
Just read, think, and it will be come clear.

coding in mono is okay, except...

[yagu]

coding in mono is okay, except..., I really hate having to wear those special glasses! You know, the ones with a green right lens, and a green left lens. (sorry, couldn't resist.... mod me down)

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.

I am a Linux User, not a Joe User.

[lysium]

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.

So everyone that enjoys Linux as it is will instead be forced to use a system of limited choice designed for the average computer user. You know, Linux made it pretty damn far without pandering to Joe User....why shift focus now? The other operating systems on the market fill that need well enough.

I mean, isn't this why people hate the US two-party political system? Too much similarities and not enough choice? You know, some might argue that too many political choices just confuse poor 'Joe Citizens' like you and me.....

=====--=====

There is more than UI. What about DI

[sasoon]

Modern programming is about copying data from one place to another. It is 40% user interface and 40% database interface, the rest is business logic. What about database persistence? What about ORM tools? Java is superior here. All database persistence layers for .Net are years behind persistence layers developed for Java. See Hibernate for example. One needs not only a UI framework, but a database framework. What can .Net can do about that? Nothing yet.

Re:There is more than UI. What about DI

[mchnz]

The DI layer is only a minor point of difference. Many developers are still using JDBC. .Net is superior at the JDBC level of coding. I read somewhere that there is an effort to port hibernate to .Net. Many good open source utils such as log4j have been, or are being, ported to .Net. I've also heard that Microsoft is looking at a ORM layer. Full J2EE will take them longer - but small to medium sized systems don't need J2EE (too heavy, too complex, good J2EE developers are too rare/expensive).

Its about time

[Anonymous Coward]

I am glad to see the direction that Linux desktops have been going. I had 1 750Mhz and found it was way too fast. So Gnome changed a bit and fixed that problem. Now I have a 3000+ AMD64 and am just sick to death of the sheer speed and responsiveness of the system. It is nice to see that the forward thinkers at Gnome have me in mind.

NR

My law

[Anonymous Coward]

I'm going to allow myself to get pretentious and suggest a "law" (more of a hypothesis if that):

Any belief which requires everyone to believe it, is doomed to fail.

People just don't work that way, and the free software world is almost certainly going to remain balkanized. There are a lot of great solutions out there to a lot of interesting problems, and everyone accepts/rejects different tradeoffs.

Anyway, I'd prefer a python solution, but I could deal with it if java won. C/C++ need to (almost completely) die for the good of the free software world. But that's just me. I bet a ton of you are already deciding that my choices suck and yours are much better.

Re:UNO allows multiple languages to access APIs

[Anonymous Coward]

For Win32 there is also a CLI-UNO-Bridge(currently in beta-state) which allows full access from a .NET environment.
It shoud be easy possible to port it to Ximians MONO, so MONO developers would have full API Access too.

CU Jorg

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.

asbestos claim

[pyrrho]

Still sensitive from an AC haunt that thinks I'm a zealot, no doubt inspired by my blowing off steam here and sometimes with semi-snarky humor, e.g. in the last Mono/C# vs. "C" thread, I want to be careful.

My pet peeves regarding these issues are not about what language to use in general. My pet peeves are somewhat more about semantics and about the arguments used themselves.

(1) C++ is high level, in fact, it's arbitrarilly high level. The distinction between C#/Java and C++ is better described with the term "managed code" as this really gets at what those languages offer that C++ cannot. Using the "higher level" language reinforces wrong ideas such as "you don't have garbage collection in C++" or "you are forced to use pointers in C++".

(2) It also peeves me when people crow about their language and insist it's the end all be all and your language is just lame. That goes for C++ too. It is not the end all be all of all languages or even compiled languages. These are all interesting technologies and we have to make decisions about them, to judge them, and which to use. If someone says "C/C++ is dead" or even "C/C++ will die" those are opinions they have a right to here on slashdot or anywhere else. However, if someone else, like me, says, "I don't buy it", and "if the idea is to not write the same low level code over and over, what do I get in managed code that I can't get with a class system or library in C++?" I know some answers to that question, and it's not "a garbage collector" and it's not "you don't have to think about memory", the answers is all about the managed code. Havoc points out some good ones, e.g. "A managed language solves some of the same problems COM was designed to solve, such as ABI encapsulation, versioning, and modularization." The answers to real questions tell you what circumstances a language is best suited for. And you will not find that one thing is taking over and everything else is dying.

UNO makes APIs transparent for any language/platfo

[Anonymous Coward]

Why replacing any API of GNOME with a Java- or Mono-API?
I think what's really necessary is a component system like UNO. It's make APIs not only accessable from any programming language or platform including Java and Mono, it's also possible to implement it in any language.
You can create any component in a different language , build it with different compiler versions, run it on distributet machines and all is working together as one system. Beside that UNO is extremly fast, which make it ready for performence critical applications like graphik sb systems.
UNO is well approved with OOo (Nearly every new code since StarOffice 5.2 is encapsulated in UNO components).

Curently the the following language bridges are available:
UNO-Java-JNI-Bridge
UNO-C-Bridge (which is written by SUN on request by Ximian)
UNO-C++-Bridge(most used Bridge)
UNO-Phyton-Bridge
UNO-COM-Bridge(of course WIN32 only, it allows access from VisualBasic and Delphi)
UNO-CLI-Bridge(This a Bridge to Microsofts .NET platform, currently WIN32 only)
UNO-StarBasic-Bridge(The Basic-Language of OOo)

There are also Bridges for some Script-Languages in development(Beanshell, Jython, Javascript). They will be part of the language independent scripting-framework of OOo2.0.

CU Joerg

Have a look at:

http://udk.openoffice.org/

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:System.Windows.Forms and DotGNU

[MenTaLguY]

It can be implemented on top of X, but that doesn't stop stupid coders who wrote SWF code on Win32 getting HWINs and the like and using pinvoke to access Win32 directly because that's they way they were used to doing something.

A non-negligable amount of people's SWF code does that, sadly.

Simply not true

[Anonymous Brave Guy]

Actually, I'd wager Java inlines more code. C++ won't inline code across functional boundaries - if you compile x.cc and y.cc then it won't inline a call in x.cc to y.cc (you get the basic picture).

I'm sorry, but that's simply not true.

For a start, optimisation across function boundaries is perfectly possible in C++. Microsoft's latest C++ compiler has a "whole program optimization" option that does exactly that, amongst other non-local tricks.

Also, the generic algorithms in C++ naturally allow far more effective in-lining than the alternatives you'd get in C or Java. The sort<> algorithm, which naturally incorporates the ordering test into the sort code and can then optimize further, is the standard example. And as with any other technology, effective optimization of generic C++ code has been a while coming, but it's improving all the time.

If you're going to highlight some advances in Java technology, you'll look less foolish if you don't compare it with five-year-old C++. :-)

2.6 actually uses a different build sequence...

[waferhead]

I know this is pedantic, the parent post was +5 hilarious, but this took me a while to figure out via googling.

make mrproper ,(then copy/otherwise set up your .config) then "make prepare && make modules && make modules_install && make install"

Please notice "make prepare".

This is essential, kernel will build but not boot if that is skipped.

Found this out on Debian and Mandrake, building custom config kernels from fresh distro provided source.

the answer?

[pyrrho]

... superlint? lint++?

A tool that loads a coding standard schema to check code (on it's way into revision control and/or at build time?).

This problem requires a new programming lang

[Anonymous Coward]

What about creating/making a new lang with all you need?

How about class loading?

[Latent Heat]

I am beginning to think that what brings Java to its knees is class loading.

Unlike Python or other scripting languages, every time you run a Java program it has to load each class that first time you create an object instance, and it does some kind of analysis on the byte codes of that class to see that it is OK and not kind of a Trojan Horse program. The idea is that Java is supposed to be secure by doing all that checking.

That checking comes at a cost that Java programs are pokey to load. Think of it this way -- Windows is pokey to load, but you load it once when you start your computer. Java is a kind of OS within an OS, and it is pokey to load every time you run an app.

I heard that the Mac has better Java on it, and they keep one image of the JVM around so once you load a class it stays loaded for the entire OS session instead of loading every time you say java myprog.

The other thing that probably brings Java to its knees is Swing on account that they tried to write Swing more object-oriented than thou and more document-view than thou and that you have gobs of little classes -- both a class loading startup overhead as well as overhead of creating and GC'ing object instances.

While people talk about "no shrink-wrap" Java apps, not only is Matlab very Java friendly, Matlab is partly implemented in Java. Matlab is a special case in that it is one of the few commercial shrink-wrap apps where having Windows/Unix/Linux versions is an important part of their business model, and I think they are migrating Matlab piecemeal over to Java internally. They say the GUI is done in Java -- if you go Files Open to open an editor window for a Matlab script file (.M file), it takes about 3 seconds to load, even on a late model P4. So you can say the MathWorks guys don't know how to program Swing correctly, or you could say Swing has some serious pokeyness in terms of loading and creating stuff.

But apart from class loading and Swing, I am not finding much that is pokey about Java.

Re:How about class loading?

[Trejkaz]

You could take the multiple programs in a single JVM approach using a system like Echidna. This does actually partially solve the memory storage issues too since the memory wasted by the JVM (8Mb or so for Sun's JVM IIRC) will only be wasted once.

But I think even Echidna does re-load the classes every time. It doesn't seem like a stretch to make a version which doesn't, but you would need to do things like keep hashes of each JAR file and check the hash every time you start an app. If the hash doesn't match, re-load the whole thing and check the signature on the class files at the same time. Then store the result back to some place in the system which the user doesn't know about.

Or of course you could just make a version of the JVM which simply doesn't care about security at all. It would put your computer at potential risk, but no signatures would ever need to be checked. Just like native code. ;-)

Byte code and sandboxing

[Latent Heat]

One part of byte code is portability. The second part is security -- you know, the original applet concept of running programs downloaded off the Web in a secure sandbox.

I think that both Java and C# are influenced by the idea that byte codes can be better sandboxed and given controlled level of privileges.

We have a C app thats been running since 1987! :-)

[Anonymous Coward]

On the same hardware! Beat that! (PS replaced once). Still same disk. *kachunk* *kachunk*

1987 Is the build year of the binary and the install year of the software (and OS). Its an IBM PC and the complier was Lattice C.

WORK! Blasphemer!

[Anonymous Coward]

Do your _WORK_!?! You don't work with computers you play with them!
And, C don't force you into any way of thinking. It forces you to understand a bit more. It gives you freedom, freedom to build what you will. When you start getting into the big Lego pieces, thats when you are forced.
When I got my first Lego set, there was no "build manual" with it. It forced you to use your brain. Many kids today get the Lego kit, build them following the manual 100% and then puts the model on the shelf (and starts beggin for a new one).
They have gone from training imagination to training the ability to follow instructions.
A lot of the coders I see today are the same way; When they run into a problem they go to the "intellsence(tm)" and try to find a ready made solution. If its not there, they start to search the Internet and a dowloadable "softIC". If they cant find it THEY ARE STUMPED! The question today is not "can you do?" but "can you find?". The majority of software development is turning into a big exam cheat...

You want a fast GUI?

[Anonymous Coward]

Go for Windows 1.0 (before those pesky overlapping Windows) Now thats some fast GUI action for ya! ;-)

But that is not what the story is about

[SmallFurryCreature]

This guy seems to want to change to something new and exciting for change sake(?) and that I can't stand. C works. Gnome works. Concentrate on other matters first. Or at least give us an example first. Code something in a new platform and show why it is better.

Too many times I see people telling stories oh if only people would use programming language X it will all be better. Frankly it pisses me off since so far noone has actually gone out and bothered to prove it. .Net is hardly a runaway success. Java is still just one of many languages. And now they are adding mono to the mix as the next saviour.

Thanks but no thanks.

I am not against mono. Add all the language hooks you want. Code your desktop in php gui version if you like. Just don't tell me it is going to save the world.

Most amazing in this type of /. article is that each time someone mentions a language I never heard of before. I am no genious but after a couple of years you would expect to have seen them all. No there is always some new language someone invented to solve all the worlds problems.

Parrot? You just made that up!

[Anonymous Coward]

There is no such thing as Parrot! (Is there? (and if there is, is it Norwegian blue?))

Server identification string and the extension

[SmallFurryCreature]

Call me strange but for some reason I presume that when the extension says PHP it really isn't java on the server. Not impossible java is used somewhere on the server but usually not. Same with extensions as asp.

Go and check the server signature and you will also see java mentioned far less often then the other platform/languages.

So far from the revolutionary language claimed by java fans it is just another tool. Suitable for some jobs, unsuitable for others. As a programmer you have dozens of languages to choose from and a decent developer knows at least half a dozen reasonably well.

I am not saying java is crap or anything like that. Same with .Net or mono. I just don't believe they are the second coming.

Re:OpenOffice.org = slower then heck!

[Anonymous Coward]

I agree, its usable but its a PAIN! My flagship (2.8 HT with 2GRAM) feels like my old 486x25 with 16MRAM. Star Office for linux was a blast! Why did Sun have to mess thing up?

C++, the forgotten alternative

[OnanTheBarbarian]

C++ seems to get mistreated in these debates; the picture of the language that people seem to have is an complete strawman. If you believed the Java/C# crowd, someone puts a gun to your head in C++ and insists that you

a) build massive type hierarchies with all sorts of cryptic overloads and exciting multiple inheritance paradoxes,

b) regularly cast things in and out of void * and use at least three unions per C file, as well as including a large number of K&R prototypes just for the hell of it,

c) use the worst possible C++ compilers available, and completely avoid any of the smart pointer implementations, C++ garbage collectors or tools like Purify that might help you with memory lifetime issues,

d) overload everything in sight, all the time,

e) write the occasional template metaprogram that generates 20K long error messages when you accidentally mess up a type in the splay tree of types implemented entirely in the language type system, and

f) utterly ignore any useful part of C++ that isn't directly expressible in Java or C#, or find compelling reasons to ignore the existence of such features - particularly if the feature was ever poorly implemented in any C++ compiler, anywhere.

C++ certainly gives you more opportunities to write bad code. In fact, it allows you to create huge frameworks that pretty much guarantee that not only is the code you write bad, but anyone who tries to interface with your code will also have to write bad code. However, it also allows the creation of good code and excellent frameworks that can get incredible things done. Well-written STL code, for example, is astoundingly terse, clear, efficient, and wonder of wonders, type-safe!

Unfortunately, there seems to be an increasing trend out there of half-educated programmers with the viewpoint: "if I don't understand it, to hell with it"!

I'm confused...

[eniu!uine]

"The future linux desktop"

Shouldn't there be a K there instead of a foot?

Re:Too bad GNOME's architecture sucks...

[borgheron]

Actually, I was speaking from experience. GNOME's architecture does suck.

Why I love C++

[Ars-Fartsica]

The built in database access framework, the clean syntax, the pervasive security model, the well-defined XML APIs, the common networking library....picking up the sarcasm yet?

No other language provides so much rope with which developers may hang themselves.

No other language is so falsely claimed to be mastered by programmers who in fact are nowhere near an intermediate level of understanding.

No other language (even Perl) produces such obfuscated code that it is illegible to other team members.

Please let this abomination die, but not before all of my competitors decide to "reimplement everything in C++", which will surely take them out of the market.

Look no further.

[Wolfier]

XFCE 4.

Granted it doesn't have Gnome hooks built-in, but it is GTK+ 2 (thus fully supports unicode), have MORE features and SMALLER than the wimpy featureless Metacity.

In fact, using your analogy, Metacity seems to be the Wolfenstein 3D.

screenshot here

c#/java vs C/C++ for gnome development.

[Anonymous Coward]

It seems to me that what c#/java offers over c/c++ was not a runtime and garbage collection but easier programming because with c#/java:
- primitive/value types (c structs) are allocated on the stack
- objects are allocated on the heap
Thus pointers cease to be an issue. I think Delphi got it right - a fast compiled language with objects on the heap. Its a pity it had a pascal syntax and not a curly brace C-ish one!

However things have moved on and modern 'best practice' C++ emphasise data objects working with template algorithm objects - not so much on traditional OO. Its back to data and algorithms. Isn't that what 'service orientated architectures' are all about.

A simplified version of c++ with templates but not gc - and without pointers being so much in your face - would i think be cool. It would give speed and control without the pain.

Also with AOP perhaps the object systems of Mozilla and Open Office could interact e.g:
@uno x = new OpenOfficeObject();
@xpe y = new MozillaObject();
@kde z = new KObject();

Re: No, .net is not just another language

[Anonymous Coward]

"Programming languages are programming languages, irrespective of who came up with them."

No this is not at all true. A programming language needs a compiler or interpreter; all of which can be covered by patents. .NET is M$'s final solution to their failed attempt to take over the future of java from SUN. (That M$ failed should be proof of how hard it ito work with something that is owned by someone else.)

We should not be endorcing, supporting, suggesting, using, talking about or anything other than ignoring .net in the free software community.

I can't believe I even had to type the word out again. Yuck.

Y-Windows

[bizcoach]

So tell me, what copyleft windowing system is it that you use? Oh, there isn't one.

the Y-Windows system is copyleft.

let me try to advocate devil

[Arioch_BDV]

I foreseeing myself beeing beaten like the poor Pingu, so i'd like to state:
The opinions expressed here are not mine but of my employer.

Oooohh... Did i really told that. No, the above lines were not my opinion as well.

Now, to be serious, i'd like to put my 2 cents over some points, i often meet around. Some of them are fro mthe article, others are not.

1) We should choose language...
No. We should choose runtime library.
Personally i'd prefer to code in Component Pascal or Borland Pascal rather than C/C#/Java branch. Just because i dislike C look-and-feel. Is it serious? i think everyone will say 'no'.
So the question is about library, it is library functions/objects that developer constructs his program with. And they are at his fingertips' cache. Moving to another library makes him significantly less productive, as he has to think 'what am i to use for my task' or even browse the manual and FAQ and so on.
Let as take MS Visual C++ and Borland C++ Builder - both of them are more-or-less C++ compilers for Win32 - and they are incompatible for any complex app, since they use (and make developer used to) different rtl's.
Let as take GCC with GTK+ and Qt and wxWindows - again, GTK pro will work slow forced to use Qt library.

Broad support for languages is very good for small tasks, such as those, solved by scripting languages. But for serious development ine will need to learn GTK+ - and it will count much less what language does he prefer.

But if we want to support many languages were are to desing RTL the proper way, so that every language will have bridges to the features above Least Common.

For example Class Factories in 90% of cases are workaround for C++ lack of class refernece type and virtual constructor.
So if RTL will make use of them - then for C++ they are to look like some special simple auto-generated Class Factory. And the opposite, such a Class Factory implemented in C++, is to be class reference to a class with virtual constructor for less restricted language.

That is very hard, and usually it is not even atttempted. Usually ether
a> RTL is Least Common for all the language - and is not comfort to any of them, so languages are quickly added with there own libraries and RTL does not guard the cross-language compatibility no more. That is not a choice at all IMHO.
b> RTL is designed for C++ (or any othe language, but oinly sole one). That makes it uncomfort for all the other laguages, hence that main language becomes the only widely used one. This way we only refactor existing GTK and maybe change C++ for some other language. If that is all - does it worth the efforts on refactoring?

IMHO RTL is to be _designed_ for some set of languages agreed before, and is to allow bridges for all the features that are not natively supported in the languages.

I do not say that ECMA .NET is good at this, but it is the only major project i know that stated cross-language support as one of its targets.

And since GTK+ set of classes might be refactored but will never be abondoned - it might try to become a standard RTL for free .NET
Though i doubt it will, there are alread ycross-platform incompatbile RTL's like Apacje's one and Mozilla's one (mostly at middle level of applications), as well as GTK and Qt (mostly as UI level of applications).
Will GTK.NET or whatever be fine and be the 1st one - it will become standard de facto, otherwise i see no chance to have one standard RTL, when we alread yahs a lot of competing ones now - will any of them want to die? only some new Terra can be base for standard RTL.

2> Free .Net implementations will speed-up MS .NET
I can't agree. Do projects like WinE and Odin spped-up Win32 ?
I think it is quite the opposite!
While projects like DotGNU and Mono are weak - the real programs are designed over MS new ideas and DotGNU and Mono are eternal step-behind compatibility layers

Why is it so bad to use .NET

[Unoti]

What's so wrong with using the .NET platform? It's a wonderful design and it works well. If it turns out to be the future of corporate software development (and it might), it'd be unfortunate for the open source community to be left behind.

I don't quite understand what's so inherently wrong with using a framework that's designed to be compatible with the published standards of .NET.

Isn't that what Linux is, a free alternative designed to be compatible with someone else's IP?

.NET and CPU's

[Arioch_BDV]

got www.DotGNU.org and read PDF about Portable.NET , particularly why the 1st goal is unroller and only after it, maybe, there appears JIT.

Result is that Windows CE may one day get full-featured .NET from DotGNU - and will get only restricted Compact Framework from Microsoft :-)

Why Mono is treated hostile to GNU.

[Arioch_BDV]

AS: afair Mono has an interpreter, along with x86 JIT.
Afair same is DotGNU.
So it does not make the differences.
Though interpreters of Mono and DotGNU really was made differently www.southern-storm.com.au/download/pnet-engine.pdf

"just call us hostile only because we have a different implementation from yours."

i'd put a quote from http://gnu.vlsm.org/projects/dotgnu/pnet.html
---
Do you cooperate with the Mono project?

In April 2002, we added I18N (internationalization) support to Portable.NET, under the usual "GPL plus linking exception" license. We were looking for ways to increase cooperation with Mono, and Mono has a policy of not accepting code under our usual license. As an experiment in co-operation, the DotGNU Steering Committee offered the I18N code to Mono under the X11 license.

Mono did use this code, but contributed very few changes to it. Meanwhile, we did a lot more work on this library, more than doubling its size. So we decided to go back to our standard license for the new version. The original version remains, of course, available under the X11 license.

We were still interested in ways of increasing cooperation with the Mono developers, in ways that would be mutually beneficial to Portable.NET and Mono, and therefore another attempt at establishing cooperation was made in October 2003. This also failed.

More focus on design.

[Anonymous Coward]

I think free software needs a designed language such as Java or C# really bad. Contributing code to freee software projects such as Gnome is really hard because you have to learn a lot of tools and languages that are all hacks. Their lack of design means the only way to learn them is to spend several years hacking their layers of obscurity, before you form an indepth understanding of all the important pieces. Being a programmer who started with assembler, then various med-level languages such and as C and only in the last few years got into high level languages Java and C#, I know the level of productivity and robustness of code gained when going from c/c++ to Java or C# is _HUGE_. I doubt the communitys ability to create something designed by itself (like Linus says the kernel isnt designed) but implementing Java or C# is definately within reach (mono/gcj). However I do think the community has to make a serious attempt at designing the API. GTK+ is very non-designed at the moment. In fact the Java-Gnome binding guys are not using the widget definition files to automaticaly create the bindings, instead they manually build a classhierachy to makes it more OO designed than gtk+ is. I dont think we will ever achieve good OO design before gtk+ and the like are implemented in an OO language, instead of C with pseudo OO. Lets see if redhat can build a fast Eclipse based on gcj. If they can do that, then it should be possible to build gtk using gcj. Eclipse has already proven at least on windows that you can build a widget set (SWT) driven by java that is just a responsive as the native widgets set. I also deminishes our efforts with design, since we could learn at lot from SWT. Unfortunately projects like gcj and java-gnome dont have that many followers, it looks like mono is going at a much higher pace. I dont mind using C# if someone would guarantie that the C# core is not encumbered by patents.

How about still using C

[Anonymous Coward]

The idea of the default gnome window manager is to get higher usability through integration with gtk and others. If you want to run a desktop on 10-15 years old pc's as they do in 3rd world countries and usability means nothing to you, then why dont you just use icewm or wmaker??

the rest of the Linux desktop ??

[IntergalacticWalrus]

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.

Oh, so the Gnome developers are going to be coding for KDE too? ;)

Seriously, call me a troll but all this "Gnome == future" crap annoys me. KDE's OO framework and flexibility kicks Gnome's weak and feature-lacking C-coded ass, not to mention Qt is vastly superior to GTK+. Yet, for some reason, it's always Gnome that gets the spotlight.

Use different tools for different jobs.

[meldroc]

Clearly, there are some jobs best done with higher level languages with goodies like garbage collection, like high-level GUI interface coding. There are also jobs that need low level, close to the metal languages like C or even assembler - anything that's CPU bound and requires high performance - games or number-crunching.

In other words, there is no One Great Language that everyone needs to switch to and use for everything. Lots of games are written with multiple languages - C for most low-level stuff, hand-coded assembler for the hot-spots, and Python for things like AI, level setup & such.

As for me, I don't much like virtual machines. You might as well either compile to native machine language or leave it in source and run it through an interpreter. VMs are just an unnecessary waste of cycles & memory, and an needless added level of complication. I like gcj's ability to compile Java to native binaries.