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).
How about still using C (Score:5, Interesting)
Does the new release improve the X performance? (Score:3, Interesting)
Visual development environment (Score:5, Interesting)
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.
High level languages (Score:3, Interesting)
I mean, we all like java, but have you ever seen a normal user application (with a GUI) written in java that is even a bit fast?
Re:How about still using C (Score:3, Interesting)
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 native machine code, allows for expandability through C/C++ plugins, and helps me effortlessly lay out my UI. It looks like a pretty solid product
Commercial Linux Apps (Score:5, Interesting)
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
Re:I have to say it: (Score:1, Interesting)
One word... Smalltalk... (Score:1, Interesting)
-- ac at work
hmmm (Score:1, Interesting)
Further, WTF is with object oriented nautilus in 2.6? Can someone explain how having hundreds of windows exploding onto my desktop as I browse is beneficial? And if it's for "ease of use" then can someone tell me how abandoning what the other 2 Major OSs are doing is "easy of use"?
Methinks there is some UseInterface Jihad warriors who could be kept under control. This is ONE thing where you do need an easy to use control panel to change between options.
Gnome is going in the wrong direction IMO.
I opened up KDE 3.2 to find konqueror quite nice actually, their tabbing is comparable to moz/fox now and the interface is cleaner. Sure KDE had "lots of options behind the scenes" but they are still behind the scenes, only one or two more "on the surface" extras to gnome.
There might well be a migration to KDE from Gnome to avoid legal issues if too many apps get developed in mono.
Language Evolution (Score:5, Interesting)
BUT I've also been doing Java and C# the last three years, and they are a *huge* win in developer efficiency. Watching people working on my projects, I can see marginal developers immediately become much more productive (2x in some cases) - and I've been measuring this using several objective metrics (modules/week, LOC, PR #, time/PR).
I would rather see Java "win", but unless Sun blinks on the free/open issue _very_ quickly, I think C# will win by default.
C++ rules and will continue to do so (Score:3, Interesting)
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.
GNOME is GNU. Mono is hostile to GNU. (Score:5, Interesting)
Re:High level languages (Score:2, Interesting)
In addition to that, you could use a native GUI - like GTK - instead of Swing, which should speed things up considerably.
Re:How about still using C (Score:1, Interesting)
A GNOME Developer speaks. Cut&Paste from OSNew (Score:0, Interesting)
Such editorials are hard to take serious since they are build up on basicly NO deeper knowledge of the matter. Most people I met so far are full of prejudices and seek for excuses or explaination why they prefer the one over the other while in reality they have no slightest clue on what parameters they compare the things.
If people do like the gance ICONS over the functionality then it's quite ok but that's absolutely NO framework to do such comparisons.
I do come from the GNOME architecture and spent the last 5 years on it. I also spent a lot of time (nearly 1 year now if I sum everything up) on KDE 3.x architecture including the latest KDE 3.2 (please note I still do use GNOME and I am up to CVS 2.6 release myself).
Although calling myself a GNOME vetaran I am also not shy to criticise GNOME and I do this in the public as well. Ok I got told from a couple of people if I don't like GNOME that I simply should switch and so on. But these are usually people who have a tunnelview and do not want to see or understand the problems around GNOME.
Speaking as a developer with nearly 23years of programming skills on my back I can tell you that GNOME may look polished on the first view but on the second view it isn't.
Technically GNOME is quite a messy architecture with a lot of unfinished, half polished and half working stuff inside. Given here are examples like broken gnome-vfs, half implementations of things (GStreamer still half implemented into GNOME (if you can call it an implementation at all)) rapid changes of things that make it hard for developers to catch up and a never ending bughunting. While it is questionable if some stuff can simply be fixed with patches while it's more required to publicly talk about the Framework itself.
Sure GNOME will become better but the time developers spent fixing all the stuff is the time that speaks for KDE to really improve it with needed features. We here on GNOME are only walking in the circle but don't have a real progress in true usability (not that farce people talk to one person and then to the next). Real usability here is using the features provided by the architecture that is when I as scientists want to do UML stuff that I seriously find an application written for that framework that can do it. When I eye over to the KDE architecture then as strange it sounds I do find more of these needed tools than I can find on GNOME. This can be continued in many areas where I find more scientific Software to do my work and Software that works reliable and not crash or misbehave or behave unexpected.
Comparing Nautilus with Konqueror is pure nonsense, comparing GNOME with KDE is even bigger nonsense. If we get a team of developers on a Table and discuss all the crap we find between KDE and GNOME then I can tell from own experience that the answer is clearly that GNOME will fail horrible here.
We still have many issues on GNOME which are Framework related. We now got the new Fileselector but yet they still act differently in each app. Some still have the old Fileselector, some the new Fileselector, some appearance of new Fileselectors are differently than in other apps that use the new Fileselector code and so on. When people talk about polish and consistency, then I like to ask what kind of consistency and polish is this ? We still have a couple of different ways to open Window in GNOME.
- GTK-Application-Window,
- BonoboUI Window,
- GnomeUI Window,
Then a lot of stuff inside GNOME are hardcoded UI's, some are using *.glade files (not to mention that GLADE the interface buil
Re:Havoc, the guy who fucked GNOME (Score:1, Interesting)
Would we? It seems to me that a lot of effort on KDE is wasted by continually reinventing the wheel, or just wasted with downright complete rubbish which shouldn't be there in the first place.
Exhibit A: KPaint. What the hell were the KDE release team even thinking? It doesn't work. What is doing in KDE?
Exhibit B: Kview & Kuickshow. KDE2 had KView, which worked, had a nice interface and was very useful. Now we have Kuickshow which is klunky, over engineered and less useful than KView. It takes a lot longer to load, too. Why?
Exhibit C: KBiff. KBiff was damn useful when I was running KDE1 all those years ago. Where is it now? Oh, it died a long time ago with the change to Qt 2.x Droping features like that is just bad.
Maybe if the KDE guys would spend some more time and actually invest themselves in less duplication and wasted effort instead of worrying about whatever GNOME are doing, wKDE would be a far better Desktop?
Re:All anyone needs... (Score:2, Interesting)
Seriously, code inside VMs has advantages, such as security and portability.
Yeah, lets all rally 'round Havoc Pennington. (Score:1, Interesting)
Letting Havoc Pennington decide what the Linux desktop should look like is like hiring Stevie Wonder for an interior decorator--He may be talented, but there are areas he should just simply stay away from. Far away from. Deciding standards for others, being among them.
Long story short, Pennington simply doesn't get the big picture of what the Linux desktop needs to be. For example he thinks having multiple, competing standards for GUI layout is a good idea. Ding ding ding ding! Hey Havoc, here comes the Oxymoron Train! "multiple standards"?!
Here's a real revolutionary idea...Instead of spending years trying to mimic every aspect of the Windows desktop, we build one of our own, with our own ideas! (*gasp*) !
Re:I didn't read all of it but... (Score:5, Interesting)
"Our guys" are gonna have to fight their guys. And if "their guys" are armed with cheap CLR/VB.net/C# runtimes (meaning there will by about 10x more), we are going to freaking lose even though we have big and complicated C/C++ howitzers.
Re:I have to say it: (Score:2, Interesting)
Sorry, i just stopped believing in the "X11 isn't slow" slogans some years ago. Of course you can say "the toolkits use X11 ineffectively". Might be true. But that's like saying "Windows is secure, only the applications suck".
Re:I didn't read all of it but... (Score:4, Interesting)
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 }
Using languages and runtimes like Java or C# helps with these issues as they were designed in from the start.
Eeek...Smalltalk and Frameworks. (Score:1, Interesting)
If that were true, programmers would be using languages like Smalltalk, and not shying away from Frameworks. A lot of reason developers use not what's best for the job, but inertia of what they know. Just look at the difficulty Apple had when it released Mac OS X, getting "classic" programmers to use Objective-C, and Cocoa.
Re:How about still using C (Score:2, Interesting)
RUBBISH. There are plenty of desktop apps written in C which work just fine. Great, in fact.
So, how is it that if "C" is the wrong tool for the job, in fact the job has been accomplished so many countless hundreds of times already?
There is no single solid good reason for modern C programmers to still be running into malloc or thread problems. There are -excellent- solutions to these tired old problems already available, freely and widely on the C-programming market.
Anyone who thinks we need -another- language for programming is suffering from that cancerous "NIH" syndrome that afflicts too many technology people.
C is good for the job. It does the job. Why is it then not a good tool?
Obsessive-compulsive technology invention/re-invention is cancer.
I'ld like to hear more about the Parrot... (Score:3, Interesting)
Quoting from Havoc's blog:
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.)
Learn more C++ folks !!! (Score:1, Interesting)
> simply technically superior to C/C++ for most > uses, desktop applications in particular.
Those who claim that do not know enough C++.
Using Boost or Loki smartpointers, C# or Java lose all the advantages they have over C++ in terms of productivity.
And properly usage of STL (including algorithms)
and templatization make C++ the most productive
language over there for non trivial projects.
One must not look at the effort needed to write
a program that do some trivial work multiply with 1000 and decide how much it take for a big project.
Take your time and learn more C++ before decide to use C# or Java.
Re:How about still using C (Score:3, Interesting)
Bullshit.
The best case scenario for a hotspot JVM is that it produces the same code as the C++ compiler. Since it has to recompile the bytecode and run the same code as the C++ version it's mathematically impossible for it to be faster. You're just buying into the propaganda where they compare fast JVMs with crappy C++ implementation compiled with optimization switched off.
For proof: in a CPU bound simulation written for a course at University, written in different languages, Java took over an hour to run the same simulation that in C took less than 40 seconds. Heck, even interpreted Haskell beat the pants off the Java versions.
Re:Visual development environment (Score:3, Interesting)
How to do it. [apple.com]
But otherwise, the parent is right. Coding an non-trivial program is non-trivial; coding a GUI on top of that even more so.
The grandparent will have to wait until software component [wikipedia.org]-oriented programming becomes popular. After all, why reinvent the (exact same) wheel over and over again if you can provide a stock software component that does the trick? It is like the electronic component revolution really -- you don't really have to worry about fabricating resistors or transistors or LEDs anymore -- just worry about how to put them together (so that it works). From there, it is just solder and dike.
XAML: hierarchical storage of application data (Score:3, Interesting)
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.
Modularisation, not integration (Score:2, Interesting)
To me useability means flexibility, which implies configurability and openness. And openness in particular means proper, exhaustive documentation - low level as well as intermediate and high level documentation. Which is more or less non-existent in current versions of Linux desktops and applications.
Another prerequisite for flexibility is modularity - not Windows style modularity, but a style of coding where modules are predominantly simple and have simple interfaces. Compare the mish-mash that is Windows, with all it's knitted spaghetti of interconnectedness, to UNIX in the old days (and, thank God, still today). The elegant simplicity of filter programs or the way inetd works illustrate what I'm talking about. This is what we need - somthing that 'as simple as possible, but no simpler', to misappropriate a well known quote.
Why not embedded scripting? (Score:3, Interesting)
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.
Re:These languages are all outdated! (Score:3, Interesting)
These ports are just attempts by Microsoft to sell
You seriously thought MSFT cares about languages other than C# and VB.NET?
Re:Language Evolution (Score:3, Interesting)
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 able to take advantage of Ruby's OO model, but accomodate a third-party library from CPAN in Perl and tie it all to a UI layer that your last project wrote in Python with no ugly transitions through object brokers or external executables. UNIX-like systems have benefited from this homogeneity for decades because of the fact that tools all have a common vision of the system, but libraries have as yet not been able to standardize on ways to communicate across calling conventions, interpreted vs compiled modes of execution and data / object models. With Parrot in that gap I see a bright future for desktop development in high-level languages (as well as many other areas).
Yes, high level languages improve productivity, and yes Java is has that attribute, but you should select a language that is the right tool for the job, and when writing desktop apps, Java is the wrong tool for most jobs.
Focus! (Score:2, Interesting)
-(free-ness)A free-as-in-beer system of comparable usability and functionality to commercial systems, that levels the playing field for developing countries, small businesses, or other entities without loads of cash to spend on commercial software;
-(Freedom)A free-as-in-speech system that empowers its users with useful technology, all of which they may apply to any non-exploitative purpose they like, without subjecting them to the whims and legal departments of the corporations who own it, and which therefore poses a significant threat to any single party which might try to restrict the way people can use their own computers and the software on it;
-(Openness)A system with an open architecture, where the kernel, file system, device drivers, window manager, desktop system, file browser, print manager, etc. are all decoupled and may be substituted or can even co-exist with any number of alternatives which might suit the user's needs more precisely;
-(Technical merit) A system that is guided by technical merit above any other purpose, that in its design and implementation represents the best effort of an entire meritocratic community beholden more to engineering principles than business strategies.
These are distinct but non-exclusive goals, each of which I see supported in the OSS community. I'm not convinced that we can effectively pursue all of these at once and hope to make significant achievements toward any of them on a competitive timeframe. Because of the forking problem, an uncoordinated step forward is also a step back. Perhaps one distribution will be a landmark of usability, but to achieve that goal its designers may have compromised on extensibility and designed it very specifically for particular implementations of assorted features, or may have used non-Free software. The accomplishments of this distro would liekly be useless to an ideal system which would meet all of the above goals- at the least, applying its improvements would require duplicated effort or extra work (opening up the architecture, developing and swapping in a Free alternative to the non-Free software).
Forking is always going to be an issue where there is complete freedom, and that's fine, but then the disparate goals of the system need to be prioritized, or else a significant strategy should be developed for how they'll be pursued concurrently.
I think Havoc's post states that C/C++ is proving an inadequate solution for pursuing (Technical merit) in a way that satisfies requirements for simultaneous (Openness) and high enough usability to make (free-ness) a significant advantage over commercial alternatives. The issue, though, is that the best alternatives compromise the goal of (Freedom).
Re:I didn't read all of it but... (Score:1, Interesting)
Its Cludge++ of macros and other hard to debug "features".
As for multilanguage features, rofl, more Cludges in the form of _T macros etc, what else hmm, no language independant way of packaging objects, except we have to bolt on COM. What else, all that code duplication between definitions and imeplementations. Im sure I can think of more cludges in C++.
At the end of the way, we hold the money, we are the ones putting food on your plate so you use what toosl we the designers choose and right now we are using C# and C++ managed extensions but this is only on a as few places as possible due to the inherant problems of C++.
Yeah and the compiler, well theyre not smart at all, i mean I have to code someconstantvalhere == variablevalue becuase the compiler cant check the == properely. More C++ issues.
Re:How about still using C (Score:4, Interesting)
1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.
Well, then I'll say you haven't spent time debugging C or C++ code. My previous job was C++ UI application development, for the last five years I've been doing Java Swing UIs. There's simply no comparing the frequency of memory leak type problems on Java and C++. I haven't had a memory leak problem in years in Java, it's just too simple to avoid.
Re:How about still using C (Score:2, Interesting)
this is rubbish! C is -still- an industry-wide, adopted, in-use, tool. everywhere i go, i see C projects. more C than anything else, in fact!
1337 and lusers (Score:3, Interesting)
It appears that Java programmers are considered the VB monkeys of today, so I don't think that's it.
Quite a few only use the languages they are taught at school, and with which they think they can get a job (those that don't have one or are afraid of losing their current job, that is). Therefore they avoid anything "exotic".
OTOH, avoiding Perl makes perfect sense.
how about OpenStep? (Score:3, Interesting)
Rubbish (Score:1, Interesting)
Re:GNOME is GNU. Mono is hostile to GNU. (Score:3, Interesting)
Here are two clear examples of hostility coming directly from Mono project leader Miguel de Icaza:
- This slashdot posting [slashdot.org] is one of several instances in which Miguel has publicly spread FUD against Portable.Net, attempting to cast a shadow of legal doubt on that project because it was started before the ECMA specs were published. According to our lawyer (Eben Moglen [columbia.edu]) what was done back then was perfectly legal, but even if that wouldn't be the case, it wouldn't matter because all the old code from back then has long been removed from the codebase anyway. These matters have been explained to Miguel, but in spite of that he has continued to spread this FUD. I think this is totally unacceptable. He also calls me and the other DotGNU coreteam members "kids", and makes other false statements that however are not so significant, hence I won't discuss them in detail.
- In response to my last proposal of collaboration, Miguel first said he's interested but when I shared some more thoughts, he responded by attacking me [ximian.com], calling my view "intellectual dishonesty" and "an exercise in deception". Of course Miguel is free to have his own opinions, and Mono is free to respond with "no" to proposals of collaboration, but he could have said "no" without attacking me like that.
Suppose that one day Microsoft starts making SCO-like attacks [groklaw.net] against DotGNU and Mono. Miguel is well aware that this is a possibility, and here [ximian.com] he has stated that "if Microsoft in fact owns patents to the technology and they require the licensing of those, we are willing to license those for the sake of our users and customers." Since this statement was made in the context of discussing the threat from the possibility of patents that MS may not be willing to license royalty-free to everyone, such buying of licenses (while compatible with the X11-style licensing that Mono is using for the affected code) would change the status of the affected code from being Free Software to it being source-available, "paid Microsoft license required" non-free software. (Novell would buy a license that allows them to distribute the code, but which probably wouldn't give others the right to distribute derivative works, hence the code would stop being Free Software). However we in the DotGNU project would not accept Microsoft's demands for patent royalties, even if that means that until the patents in question have been invalidated by a US court of law we can distribute some code only from ftp servers outside the US. In view of these different planned reactions to any demands for licensing royalties it seems quite possible that Novell would agree to make Mono non-free (probably still free as in beer, but no longer free as in freedom), while we'd have to fight the legal battle against MS without their help. In view of this possibility, I consider remarks from Miguel like those quoted above which attack the DotGNU project's legal position to be extremely hostile.Don't Discount Firefox/Mozilla (Score:4, Interesting)
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.
Re:How about still using C (Score:3, Interesting)
The fact that most commercial software companies are allergic to the idea of giving their customers legible source code.
If interpreted programs ran as fast as bytecode (they're almost as fast), there would still be resistance because publishers don't want to send out software that can be read.
And what about other High level languages (Score:3, Interesting)
Each time somone talk about moving from C to some others languages, we heard about C++, C# or Java. All are kind of OOL, but whatabout typed functionnal programming languages ?
I'm using OCaml [inria.fr] every day, for many things (in the CDuce interpreter, see www.CDuce.org [cduce.org], but also in other coding projects.) And it is fast (nearly as C, just take a look at this language benchmark [bagley.org]), it is in some way safe (the famous : "Well typed programs cannot go wrong"), it has a good interaction mechanism with C librairies, programs can be compiled in native or in bytecode, OCaml native code compiler is giving very good result on many arch/OS ...
And, speaking about gnome, there's also a "wrapper" for GTK and GTK2 (called lablgtk and lablgtk2.)
Re:Please not .net.. (Score:2, Interesting)
- A modern GUI toolkit
- File and network I/O
- Decent string handling
- Common data structures and algorithms, so we don't have to write 1,000 hash tables and 1,000 quicksorts
- An interface to existing C libraries
The language also needs to be able to attract a large number of developers (which rules out Lisp, Scheme, OCaml etc) and needs to be suitable for large collaborative projects (which arguably rules out Perl, Python and Ruby).Java/GTK/gcj seems to be the only thing that meets the requirements and works now.
Re:Visual development environment (Score:3, Interesting)
Hello? COM/XP-COM objects, .NET assemblies, CORBA, Java packages. Component design is already popular. Just not so in the Linux world. That is part of what Havok Pennington is trying to address in his article.
If there was any sanity... (Score:3, Interesting)
Works with everything we have today? Check, there's compatibility with KDE and GNOME applications as well as Motif, with window style hints too.
High level language support? Check, Objective-C provides Smalltalk-like object orientation, and automatic memory management is available. There are also bindings to Ruby and Java. You can even build Java applications with native quality look and feel.
Compatible with what programmers know today? Yup, Objective-C is a slight superset of C, so almost any programmer can get to grips with it in a weekend. (Speaking as someone who did.)
Good class libraries? Yes, modeled on NeXT's excellent work, the same foundation used to build OS X. I've written Cocoa code, it's the most painless class library I've encountered. (Yes, I write Java too and have written C++.)
Cross platform? Yes again, programs are portable between GNUstep and Cocoa without too much work--see GNUmail [collaboration-world.com] for an example. Non-GUI programs even port to Windows without major effort, allegedly.
Good developer tools? Again, yes. Excellent developer tools on OS X. Doubtless the free tools [gnustep.org] on Linux could use some work [gnustep.org], but that shouldn't be too hard. We can even build them using the OS X tools if necessary.
Pretty UI? Well, I think it looks OK. Not as nice as Aqua, but it's functional.
Mature? Well, the Objective-C compiler is GCC, Apple use it for their developer tools and push back improvements, the class library design has been refined over the course of 10+ years.
Think about it, people. We could unify the Linux and Apple developer communities. All work towards one common goal. Get 10%+ desktop market share for OpenStep/OS X/GNUstep in no time.
Hell, get GNUstep up to scratch and you'd probably see developers porting their commercial applications from OS X to Linux. Wouldn't you like to see products from Adobe, Macromedia, maybe even Apple available to run on your Linux desktop?
Think about all the problems that have been solved by NeXT and Apple. Application packaging? Solved, applications are bundles of files that you can just drag-drop wherever you want to keep them, and they work.
But no, the GNOME crowd will shun a tried and tested, open source, native code solution that works today and is backed by the single biggest vendor of UNIX desktops, in favor of cloning an untested patented bytecode-based Microsoft solution. Gates and co must be laughing.
But hey, go GNOME. Let's reinvent those wheels. Maybe your next set won't be square.
Re:I didn't read all of it but... (Score:2, Interesting)
You can actually write C++ code without pointers, new and delete (provided the libraries you use don't require it somehow). You achieve this via STL. For example, to read the contents of a text file you can use sth similar (may contain bugs, did not try to compile) :
you can even create trees without pointers - to achieve this simply use a map - every node has an int id (like a primary key) - this id is a key in the map - the value is the node. The node looks like this:and you store the nodes in a map like this:
By using a set you can ensure, that you won't reference several times from one parent to the same child. Such trees are very easy to store in a database, as you can imagine.
One of the problems with not using pointers is achieving polymorphism, since you cannot store derived types in a container, but it turns out that virtual functions are not that often necessary (at least that's my case).
Another issue are iterators - because of speed(?) they are not boundary checked, so if you
over a vector of 50 elements and then doyou have an ooops !!! you can hovewer reference elements in sequence container like this:which would throw an exception in case of a 50 element vector v.I wonder why nobody seems to
- Use C++ w/STL and avoid pointers - they are seldom needed
- Solve the problem with iterators (implement boundary checking - that can't be that difficult!).
I have been writing C++ / Java programs for several years and from my own experience, if you really use many of C++ features and avoid certain pitfalls, there is little more Java can offer - it doesn't even have the approx. 50 algorithms that STL has!I have also done some benchmarks for myself - if you replace STL containers with plain arrays, you get a 6x speed gain. I don't believe Java with all its objects is similar in speed to a properly coded C app - maybe both are so fast it doesn't matter, but a C app should be about 10 times faster than a similar Java app with all objects in their places!!! ;)
one root problem (Score:3, Interesting)
When it comes to memory usage welcome to the real world of tradeoffs. I would rather pay more cash for extra memory than waste time while my apps crash because they use languages that don't protect developers from their own mistakes.