Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
GNOME GUI Programming Software IT Technology

Coding The Future Linux Desktop [updated] 700

Posted by timothy
from the they'll-use-keyboards dept.
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).
This discussion has been archived. No new comments can be posted.

Coding The Future Linux Desktop [updated]

Comments Filter:
  • by Realistic_Dragon (655151) on Wednesday March 17, 2004 @08:46AM (#8587878) Homepage
    [] 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
  • by Xargle (165143) on Wednesday March 17, 2004 @08:46AM (#8587882)
    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?
    • by Anonymous Coward on Wednesday March 17, 2004 @08:54AM (#8587924)
      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.

    • by IamTheRealMike (537420) * <mike@plan99.net> on Wednesday March 17, 2004 @08:57AM (#8587938) Homepage
      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 [gooeylinux.org]) 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.

      • by Anonymous Coward on Wednesday March 17, 2004 @09:28AM (#8588105)
        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.
      • by ichimunki (194887) on Wednesday March 17, 2004 @09:44AM (#8588253)
        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).
      • by Moraelin (679338) on Wednesday March 17, 2004 @09:53AM (#8588343) Journal
        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.
        • by pivo (11957) on Wednesday March 17, 2004 @11:43AM (#8589342)

          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.
        • by egomaniac (105476) on Wednesday March 17, 2004 @12:56PM (#8590153) Homepage
          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.
      • 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 t
      • Remember SWT (Score:3, Insightful)

        by Kingpin (40003)
        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 [eclipse.org], 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.
        • Except (Score:4, Insightful)

          by SuperKendall (25149) * on Wednesday March 17, 2004 @11:21AM (#8589123)
          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.
          • by MenTaLguY (5483) on Wednesday March 17, 2004 @12:35PM (#8589917) Homepage
            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.

      • by Lysol (11150) on Wednesday March 17, 2004 @10:36AM (#8588715)
        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.
    • by 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 [realsoftware.com] (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 nat

      • by RailGunner (554645) on Wednesday March 17, 2004 @09:30AM (#8588128) Journal
        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.

    • by NonSequor (230139) on Wednesday March 17, 2004 @09:10AM (#8587998) Journal
      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.
      • 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.

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

  • by Colin Smith (2679) on Wednesday March 17, 2004 @08:50AM (#8587903)
    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.

    • by jcupitt65 (68879) on Wednesday March 17, 2004 @09:57AM (#8588390)


      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.

  • by Chalybeous (728116) <chalybeous@nosPAm.yahoo.co.uk> on Wednesday March 17, 2004 @08:52AM (#8587910) Homepage Journal
    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.)
    • by maxwell demon (590494) on Wednesday March 17, 2004 @09:39AM (#8588208) Journal
      I'd love to adopt Linux but am still trying to mount /dev/clue ;-)


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

      You see, it's really not a problem, is it?
  • I have to say it: (Score:3, Insightful)

    by vasqzr (619165) <vasqzr@netscaDEGASpe.net minus painter> on Wednesday March 17, 2004 @08:53AM (#8587914)

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

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

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

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

  • Please not .net.. (Score:3, Insightful)

    by D-Cypell (446534) on Wednesday March 17, 2004 @08:53AM (#8587915)
    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\
    • by krumms (613921) on Wednesday March 17, 2004 @09:46AM (#8588273) Journal
      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.
      • In this way (Score:3, Insightful)

        by SuperKendall (25149) *
        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 Window
  • by nycsubway (79012) on Wednesday March 17, 2004 @08:53AM (#8587916) Homepage
    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.

    • by nikster (462799) on Wednesday March 17, 2004 @10:13AM (#8588506) Homepage
      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.
  • High level languages (Score:3, Interesting)

    by lofoforabr (751004) on Wednesday March 17, 2004 @08:55AM (#8587926) Homepage
    ...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?
    • by iapetus (24050) on Wednesday March 17, 2004 @08:57AM (#8587936) Homepage
      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.
      • 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
  • by commander salamander (256114) on Wednesday March 17, 2004 @09:02AM (#8587961) Homepage
    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.
    • +5 Insightful (Score:4, Informative)

      by 0x0d0a (568518) on Wednesday March 17, 2004 @10:00AM (#8588418) Journal
      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.
  • by seguso (760241) on Wednesday March 17, 2004 @09:06AM (#8587977) Homepage
    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.
    • 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?
    • by fnc (666371) on Wednesday March 17, 2004 @12:55PM (#8590142)
      Why is this post considered funny? Functional programming languages are very expressive. Ocaml, for example, also allows OO, and have better performance than Java, acording "The Great Computer Language Shootout": http://www.bagley.org/~doug/shootout/craps.shtml
  • Language Evolution (Score:5, Interesting)

    by nonmaskable (452595) on Wednesday March 17, 2004 @09:07AM (#8587987)
    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.
    • by ajs (35943)
      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 [parrotcode.org] as a back-end. You'll be a
  • by NicenessHimself (619194) on Wednesday March 17, 2004 @09:07AM (#8587989)
    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 (Score:4, Insightful)

    by UltimaGuy (745333) on Wednesday March 17, 2004 @09:09AM (#8587996) Homepage

    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 (Score:4, Insightful)

      by IamTheRealMike (537420) * <mike@plan99.net> on Wednesday March 17, 2004 @09:49AM (#8588304) Homepage
      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.

    • Hear, Hear! (Score:5, Insightful)

      by ultrabot (200914) on Wednesday March 17, 2004 @09:55AM (#8588374)
      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.
  • by Cthefuture (665326) on Wednesday March 17, 2004 @09:10AM (#8587999)
    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?
    • by Khelder (34398) on Wednesday March 17, 2004 @09:51AM (#8588326)
      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.
    • by Hard_Code (49548) on Wednesday March 17, 2004 @09:53AM (#8588346)
      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.
    • by IamTheRealMike (537420) * <mike@plan99.net> on Wednesday March 17, 2004 @09:55AM (#8588369) Homepage
      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.

    • by PhrostyMcByte (589271) <phrosty@gmail.com> on Wednesday March 17, 2004 @10:15AM (#8588518) Homepage
      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#.
  • by bizcoach (640439) on Wednesday March 17, 2004 @09:10AM (#8588002) Homepage
    I find all this talk about GNOME possibly becoming based on Mono extremely unsettling. GNOME is part of the GNU project [gnuwww.epfl.ch]. The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with [dotgnu.org].
    • by RdsArts (667685) on Wednesday March 17, 2004 @10:20AM (#8588568) Homepage Journal
      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.
    • 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
  • XUL (Score:4, Informative)

    by Anonymous Coward on Wednesday March 17, 2004 @09:10AM (#8588003)
    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
  • What happened... (Score:4, Insightful)

    by Bluesman (104513) on Wednesday March 17, 2004 @09:23AM (#8588075) Homepage
    ...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... (Score:3, Informative)

      by 0x0d0a (568518)
      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.
      • by Bluesman (104513)
        >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.

        No
  • YES (Score:5, Insightful)

    by Hard_Code (49548) on Wednesday March 17, 2004 @09:27AM (#8588099)
    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.
  • by Junks Jerzey (54586) on Wednesday March 17, 2004 @09:28AM (#8588106)
    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.
    • For GOD'S SAKE (Score:5, Insightful)

      by 0x0d0a (568518) on Wednesday March 17, 2004 @09:35AM (#8588179) Journal
      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#.
    • by tal197 (144614) on Wednesday March 17, 2004 @09:47AM (#8588289) Homepage Journal
      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.
  • by SmallFurryCreature (593017) on Wednesday March 17, 2004 @09:34AM (#8588161) Journal

    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?

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

    by wasabii (693236) on Wednesday March 17, 2004 @09:48AM (#8588295)
    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 ???? (Score:3, Informative)

      by zhenlin (722930)
      No need for either.

      XUL [mozilla.org] 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.
  • by mysticgoat (582871) on Wednesday March 17, 2004 @10:09AM (#8588477) Homepage Journal

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

    • 1337 and lusers (Score:3, Interesting)

      by ultrabot (200914)
      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 mak
  • by leandrod (17766) <l.dutras@org> on Wednesday March 17, 2004 @10:32AM (#8588679) Homepage Journal

    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.

  • by SloppyElvis (450156) on Wednesday March 17, 2004 @10:46AM (#8588797)
    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.
  • by Lodragandraoidh (639696) on Wednesday March 17, 2004 @10:47AM (#8588809) Journal
    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. :(
  • how about OpenStep? (Score:3, Interesting)

    by cygnus (17101) on Wednesday March 17, 2004 @12:34PM (#8589898) Homepage
    .../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.
  • by Larthallor (623891) on Wednesday March 17, 2004 @12:42PM (#8590000)
    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
  • by mattgreen (701203) on Wednesday March 17, 2004 @01:12PM (#8590297)
    The D language [digitalmars.com] 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.

  • by randall_burns (108052) <randall_burns.hotmail@com> on Wednesday March 17, 2004 @01:23PM (#8590408)
    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 [technicalpursuit.com].
    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 [mozart-oz.org] 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.

  • by lupus-slash (132575) on Wednesday March 17, 2004 @01:40PM (#8590581)
    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

Advertising may be described as the science of arresting the human intelligence long enough to get money from it.

Working...