| |||||||||||||
GNOME and high-level languagesGNOME and high-level languagesPosted May 12, 2005 14:58 UTC (Thu) by liljencrantz (subscriber, #28458)In reply to: GNOME and high-level languages by dhess Parent article: A new Harmony Project
I would very much like to see a solution where code included in the default Gnome desktop could be written in any language so long as there was a standard way to automatically generate high quality bindings for any other supported language.
I see three ways of doing this:
1) Make sure you can always generate C bindings, and use one of the binding generators to generate all other bindings. If I'm not mistaken, Java, Mono and Python should all be able to do this. Java has a bit of a head start because you should be able to wrap something around CNI to move from C++ to C and make some form of bridge that removes the idiotic Java style strings, and makes sure the Java GC interacts nicely other GCs and with non-GC languages.
2) Try using Corba/Orb or some messaging bus. This has been tried a large number of times, and it always ends up as a spectacular failure. But maybe a less ambitious approach, like specifying a communication protocol on how to talk to libraries over DBUS, would have a chance.
3) Pick the one true VM, and make everything run on it.
(Log in to post comments)
GNOME and high-level languages Posted May 12, 2005 21:47 UTC (Thu) by ncm (subscriber, #165) [Link] "I would very much like to see a solution where code included in the default Gnome desktop could be written in any language..."Meaning, I have to have VMs for every godforsaken language always running because programs are cobbled together out of bits that individually need this one or that one, but of course never the same one. Any given program might need any mix of them, and who can keep track? No thanks. As it is, with C and C++ libraries, programs don't need any particular runtime support environment, and everybody (even the godforsaken) can call them. You can write C# programs, and I can ignore them. You can write Java programs, and I can ignore them too. I'm never in danger of needing to install a JVM just because, say, some bloated spreadsheet-cum-word processor project suddenly discovered a corporate need ignore all the low-impact database engines in C, and call up a slow and immature Java database instead.
GNOME and high-level languages Posted May 12, 2005 23:30 UTC (Thu) by liljencrantz (subscriber, #28458) [Link] I want software like Beagle, F-Spot and Tomboy to be integrated with my desktop. As for word processors, I use emacs and TeX, so I don't care what features Open office includes. But as far as I understand, Oo.o actually starts up much _faster_ in the new, evil mega-Java-bloatware version than it ever did before.
If you dont want new, cool and inovative software, but feel the need to use a slow, bloated C++-based office app like Oo.o 1.x, you and I clearly want different things out of our computers.
GNOME and high-level languages Posted May 13, 2005 6:18 UTC (Fri) by ncm (subscriber, #165) [Link] If you want programs like Beagle, F-Spot and Tomboy integrated, by all means write programs like them in an unencumbered language, and integrate them. You certainly don't need one of these crippled languages to write cool and innovative software.If OO.o starts up faster than before, you can be certain it's not because they also have to start up a VM on top of everything else. I'm betting they don't start that up until you call something that needs it, or they start it in background so it looks like it's all up while that stuff is still flapping to get airborne. (BTW, doesn't Emacs define bloat any more?)
GNOME and high-level languages Posted May 13, 2005 7:24 UTC (Fri) by liljencrantz (subscriber, #28458) [Link] I strongly belive that a modern high level language with garbage collection, object orientation, exceptions and such features make high level GUI software easier to write. Is there anything in Beagle that would be impossible to write in C? Of course not. But it would have taken more time, and given that time is finite, this means that the program would have less features, or maybe it wouldn't even have been released.
Allowing people to choose what language to code in allows them to be more productive, since different people like different languages, and different problems are suited to different languages. You are right that if we where to allow the core libraries to be written in Python, Java, Ruby and C#, they would be dog slow. To me, this means that the VMs have to be fixed to become leaner, not that those languages should be forbidden.
BTW, don't think that I don't like older languages like C or C++. I love C and I use it often. I just love the freedom to choose programming languages more.
As to your comments about emacs and bloat, emacs (CVS version 22.0.50) takes about 1.5 seconds to start up on my computer. This is obviously pretty bloated and far to long to be acceptable. I just tried starting OpenOffice (v1.1.2) a few times, it took about 4 seconds on average. So no, emacs does not _define_ bloat, and the fact that you ask this implies that you don't even use OpenOffice, but still you complain about what it does and how it does it.
GNOME and high-level languages Posted May 13, 2005 13:22 UTC (Fri) by ncm (subscriber, #165) [Link] Irony is lost on some people. Anyway, who's this "we"?
GNOME and high-level languages Posted May 13, 2005 16:11 UTC (Fri) by ncm (subscriber, #165) [Link] By the way, C++ is unencumbered, supports OO anywhere it's useful, has exceptions that actually work (i.e. actually reduce the amount of error-handling code in your program, instead of multiplying it), and provides the benefits of garbage collection without its ... problems.
If you're talking about modern, though, you neglected to mention compile-time type inferencing. The MLs have it, Haskell has it, C++ has it, Java and C# don't. (What good is it, anyway? It enables writing libraries that are more powerful than is possible in weaker languages.) As modernity goes, Java 1.5 and C# are stuck at about 1991; Java 1 was about 1986.
|
|||||||||||||