Coding The Future Linux Desktop [updated] 700
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).
Eeek... (Score:2, Insightful)
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.
Community standards... (Score:4, Insightful)
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
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.)
I have to say it: (Score:3, Insightful)
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)
Feels like 10 years building a viable alternative to Microsoft and just as the goal is in sight... handing it over
And now, the rest of the story (Score:5, Insightful)
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.
All anyone needs... (Score:2, Insightful)
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:High level languages (Score:5, Insightful)
Re:How about still using C (Score:5, Insightful)
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.
Re:I have to say it: (Score:0, Insightful)
One would think that dual Xeons and 4GB memory would be enough for XP, but I guess not.
Never in Mono (Score:4, Insightful)
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:How about still using C (Score:5, Insightful)
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 didn't read all of it but... (Score:5, Insightful)
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:Language Evolution (Score:1, Insightful)
Re:Eeek... (Score:3, Insightful)
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.
Why Linux will never beat Microsoft or Apple (Score:4, Insightful)
>"Do not integrate, do not unify, be free."
If I have Windows, I download a Windows binary and USE it (ok, I might have to choose the Windows version, but that's all).
If I have a Mac, I download a Mac binary and USE it (ok, I might have to choose the MacOS version, but that's all).
If I have a Linux or BSD distro, what do I need to do? Why are the end-users asked to know what their OS is? What the hell is a dependency? Why should I have to know how to compile (or even know what "compile" is)? Why can't something for Mandrake/GTK work on Slackware/Gnome?
While I agree that choices are good, this is what is slowing down Linux development (too many options to support) and is also what confuses the normal end-user (can't even *choose* what to download, I won't even get into installing the damn things).
Stop thinking as programmers and stop saying immature things like "the user should understand his PC, know about KDE/Gnome, X, insert_random_lib_name_and_version_here", because last time I checked, 99.9999% of car drivers out there only know how to fill their gas and windshield cleaner tanks. But they all still own and use their cars.
We have people who can barely use Windows or MacOSX, they would have no chance in hell with Linux.
If you take this as a flame or a troll, then you're indeed the proof that you don't have the slightess clue about what end-users want/need/understand.
Microsoft and Apple understand this YEARS ago (even if Microsoft still don't know how to make decent software at decent prices).
What happened... (Score:4, Insightful)
I think this is going to bite them in the ass. Instead of putting all of their eggs in one basket, I think a better focus would be to improve all of the bindings to higher level languages. I'd REALLY like to be able to code for gnome in Lisp, but the bindings just aren't there.
Mono and KDE seem to have the right idea. They're making what looks like a first class development platform. With the limited time I have to code, if the development platform is working against me, I'm going to drop it. Gnome's development tools are awful. Kdevelop is much better, and Mono looks promising.
And wasn't this the whole point of basing Gnome on Corba in the first place, so that you could later incorporate objects from other languages? It seems to me like they haven't thought this through at all. Use of Corba seems to be extremely limited...probably because it's a pain in the ass to use and the project has done little to make it easier for developers.
If I could suggest a direction, I'd say concentrate on Gnome the development platform, instead of Gnome the Environment that Launches Mozilla and OpenOffice. The developers they'd attract will then take care of the rest. Solve the language interoperability problem, make sure bindings are up to date, and the apps will follow.
That's great if you ignore interoperability (Score:5, Insightful)
Do not integrate, do not unify, be free.
Be free to have to specify each individual UI preference for every new app I use, you mean?
Be free to have to spend hours trying to get my new word processor to talk to my printer?
You're kind of missing the point re: integration, I think.
Re:Eeek... (Score:4, Insightful)
I doubt they are using Java and Mono because they are "trendy". If anyone strays more from "trendy" things, it'll be developers. We use what is best for the job, be it C or C#.
If you have ever coded in one of these languages you would know it increases productivity beyond anything possible in C or C++. They are easier to code, easier to debug, easier to manage. Processors are getting fast enough to handle the small speed decrease of using a JIT. Languages like these are the future- C/C++ will easily be phased out as much as ASM was, as soon as the JITed languages become fast enough.
I am asking same question again - why Linux world need to copy everything from Windows world? Do not integrate, do not unify, be free.
Being so loosely integrated is one of the major limiting factors on linux advancing anywhere in the desktop world. Sure- having a ton of choices is great for development and customization, but for Joe User it is hell to have to learn so much crap to get things working. And if he asks his friend for help, chances are the friend will be using something entirely different and not be able to give much if any.
While Windows has it's faults, it is king of integration. It is also the driving force for a lot of new technologies. It sucks, but unless Linux apps want to be left behind, they have got to be more like Windows apps. Copying from them is OK in my book, so long as they don't copy MS's security practices
YES (Score:5, Insightful)
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
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:How about still using C (Score:4, Insightful)
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.
So the goal really is to follow Windows? (Score:5, Insightful)
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:How about still using C (Score:5, Insightful)
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.
Java, still around eh? (Score:4, Insightful)
Ever since I started to work in computers years back java been around as the great solution. First it would change the web. Remember all those applets? Gone. Then it would change web pages on the server. Well that is still hanging around but I see more perl/asp/php then java.
It was supposed to be cross platform. Well I use the azureus bittorrent client and it is indeed cross platform. It is also a bit of a resource hog.
And that really is my problem. While intrestting in many ways java has always left me with the impression that its insides are a mess or the people who code for it are on 2gig memory machines.
Lean and efficient are words I look for in my desktop. Java would not be the first language I would think off.
For years people been predicting the death of C and it hasn't happened yet. Could this be a clue? That perhaps all the pretenders are just that? Pretenders without any hope of ever coming close to the true king of programming languages?
If this guy really wants a mono or java desktop then let him fork gnome and code it his way. Prove that java/mono is the better way.
Surely that is the opensource way? He got an itch, let him scratch it.
As an aside, anyone know how much of suns java desktop is actually written in java?
For GOD'S SAKE (Score:5, Insightful)
AAAAAAAAAAAAAUUUUUUUUUUUUUUUUGGGGGGGGGGGGGGGGHH
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:How about still using C (Score:5, Insightful)
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).
some postings here scare me (Score:3, Insightful)
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:Please not .net.. (Score:4, Insightful)
Feels like 10 years building a viable alternative to Microsoft and just as the goal is in sight... handing it over
Bah. Programming languages are programming languages, irrespective of who came up with them. Developing software for Linux with
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:So the goal really is to follow Windows? (Score:5, Insightful)
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:
True, you loose static type checking. However:
XAML or ???? (Score:3, Insightful)
MS is successful because it makes programs people want... regardless how much the design of those programs suck.
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:Never in Mono (Score:4, Insightful)
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:I didn't read all of it but... (Score:5, Insightful)
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:Too bad GNOME's architecture sucks... (Score:2, Insightful)
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.
Re:How about still using C (Score:5, Insightful)
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.
Hear, Hear! (Score:5, Insightful)
My sentiment exactly. If Gnome is going to start stockpiling stuff written in C#, it becomes something you can't rely on always being available (i.e. it's over immediately after MSFT thinks they've been entertained enough). The moment C# is starting to creep in is the time Gnome should be forked. Or at least the applications that are written in C#.
BTW, what does Sun think of C# in Gnome? They are contributing to the project, I would suppose that C# has no place in Java Desktop System
KDE is starting to look more and more appealing every day. This is a sad thing to watch - on the one hand Gnome has great initiatives and innovative people, on the other hand we have people who seem to have missed the cluetrain and can't foresee the impending demise of non-MSFT CLR.
I for one don't want out Linux desktop future to be built on Microsoft-owned land. Look at SCO, you can start litigation and fuel FUD even with less obvious IP claims than Microsoft has for Mono.
They most certainly are the way to go. (Score:3, Insightful)
Computer time is a flow. Every 18 months, hardware is roughly running twice as quickly.
Arguing that virtual machine based software is inefficient is like arguinig that MPEG layer 2 audio compression is supperior to MPEG layer 3 because it takes less CPU time to decode (or MP3 vs. OGG Vorbis). Maybe that mattered on a DX4 100 Mhz machine that couldn't decode an MP3 in realtime, but it certainly doesn't matter on my XP1700+ where the bottleneck is typically the O of the algorithm, not if it's interpretted (since VMs are as fast, now, as native code in the majority of cases).
Re:One word... Smalltalk... (Score:4, Insightful)
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.
Re:Eeek... (Score:3, Insightful)
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:Java, still around eh? (Score:3, Insightful)
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:Visual development environment (Score:2, Insightful)
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$
Re:How about still using C (Score:3, Insightful)
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:Please not .net.. (Score:2, Insightful)
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
They win, we lose.
Re:Visual development environment (Score:5, Insightful)
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:How about still using C (Score:3, Insightful)
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:I didn't read all of it but... (Score:4, Insightful)
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:
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:GNOME is GNU. Mono is hostile to GNU. (Score:5, Insightful)
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
Remember SWT (Score:3, Insightful)
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.
Re:How about still using C (Score:2, Insightful)
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/dyn
(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.
that's OSX (Score:4, Insightful)
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 (Score:4, Insightful)
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?
Never underestimate an M$ technology. And I keep thinking of how many projects I've worked on where they code to IE and its standards complaint HTML that does not render in anything else. If you think that HTML is in the clear for now and the near future, you're mistaken. I think it's even a struggle now to keep people from just coding to IE. In the business world, where 99% of all the desktops run Windoze, any HTML project will probably only code to IE. For them, there's no reason not to.
I think Havoc is dead on the money with this one. XAML is a threat to HTML and it's needs to be watched and one-upped by the free/open community out there - he's bringing up the right arguments. If not, then there will be little reason for people to even use HTML at all. And like I said, if there's no reason for people to develop to an HTML standard, then there will be no reason to develop to HTML at all.
As for Mono; I also agree with Havoc here in that free alternative technologies should be developed outside M$ and not with it. Until M$ want's to be a regular member of the technology community and not the sole owner of everything, then they can't be trusted. And this is not just a rant but an opinion based on their historical behavior.
While, again, I think the Mono and dotGnu guys are doing a good job, I think their efforts are misplaced. Maybe at a minimum, provide a c# compiler like gcj. But all this Winforms and the like and doing Linux client apps in c# is going to be more of a problem than a solution.
As far as using Java to do app? Hey, at least Sun has an interest in seeing Linux succeed; read: Sun will, like IBM, make more money on Linux at some point than Solaris. M$, on the other hand with their current business model, sees NO benefits from Linux succeeding. So, again, I agree with Havoc.
Re:How about still using C (Score:3, Insightful)
What's worse is that C forces you into a certain way of thinking.
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 (Score:5, Insightful)
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.
Question on C# vs. Java (Score:3, Insightful)
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:XUL (Score:2, Insightful)
Hmm. Similiarly, I don't think there was much interest in doing GNOME in Java until Microsoft released their Java feel-alike.
Re:How about still using C (Score:2, Insightful)
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?
Comment removed (Score:2, Insightful)
Except (Score:4, Insightful)
Except that they are not poerting things like windows.forms, so just about nothing written for
Mono makes a great tool for migrating Linux programmers over to Windows though.
In this way (Score:3, Insightful)
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:Why Linux will never beat Microsoft or Apple (Score:3, Insightful)
>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:Python (Score:5, Insightful)
Read about Duck Typing [everything2.com] on e2.
Re:Why is Java no good for Linux? (Score:1, Insightful)
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.
End Rant
Re:How about still using C (Score:3, Insightful)
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.
We're missing the point (Score:3, Insightful)
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
Re:These languages are all outdated! (Score:4, Insightful)
Re:How about still using C (Score:5, Insightful)
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.
*sigh* (Score:3, Insightful)
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
Language bindings are a nice thing, aren't they?
Re:How about still using C (Score:3, Insightful)
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.
Yes (Score:3, Insightful)
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
Re:How about still using C (Score:3, Insightful)
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.
Cry Havoc! (Score:3, Insightful)
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?
System.Windows.Forms and DotGNU (Score:3, Insightful)
This isn't true. The implementation of DotGNU Portable.NET [dotgnu.org] proves that it can be implemented directly on top of X, without any need for Wine or winelib.
Re:High level languages (Score:2, Insightful)
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