December 12, 2004 15:56:30.490
If you want to read your GMail in your aggregator, have a look here at Google's support page for that - Bf is their only recommendation for Linux.
Update: Apparently, you need a GMail account to see that page...
Vincent Foley] December 12, 2004 19:54:41.896
I think it's in a way sad that BottomFeeder is the only mentionned aggregator that runs on all three major platforms (Windows, Mac and UNIX.) I mean it's great, I really like BF, but why do so many people write code in platform-specific languages? Where are the aggregators written in Python? In Ruby? In Java (write once, run everywhere!)?
[Dave Walker] December 13, 2004 14:01:02.522
I can't speak for others, but for myself (a "techie" user who has probably used over 2 dozen aggregators on various platforms), there are things that native applications (meaning: written in your OS' native application frameworks) give you that even the finest applications written to a virtualized platform ordinarily don't:
James Robertson] December 13, 2004 15:22:10.501
As to Mac issues, Bf will be better on the Mac when VW is (within a release or so).
[Vincent Foley] December 13, 2004 15:43:10.328
1. Fast startup
Sure, something written in C might (that's application dependant most of the time) start faster than something written in Smalltalk, but maybe the Smalltalk application has less chances of a fast shutdown due to a segmentation fault ;)
2. Small footprint
That depends on the VM used. I'm not very familiar with the VisualWorks VM, so I won't comment on it, but I know from experience that the Java VM is big. However, I don't think that in a language like Lua the footprint would be that much higher than an application written in C++ (it could even be less.) Also, if the programmer was a pig and decided to store everything in RAM, well maybe the design of the application is to blame more than the language.
3. Raw performance
Well, considering I've seen programs written in O'Caml, SML, Common Lisp and Scheme beat C and C++ in benchmarks, I don't think that performance is really that much of a problem. Actually, I believe that the more people get interested in high-level languages, the faster the implementations become and that really soon it's not even gonna be an issue.
4. Tight integration with other applications in the user's environment
I guess this is due to bindings in the language. If a language has those bindings, integration is possible, so it's just a matter of having the right libraries for the language.
5. Native look and feel
Yeah, I can't not give you this one. BottomFeeder really stands out on any platform I use (Windows, Linux and OSX), so do Java applications.
[Dave Walker] December 14, 2004 11:37:33.994
In fairness, most of my experiences with virtual machines as an end-user have been with Java, but then that's probably true of most end-users. I have several Java apps that I use daily or at least many times per week (Azureus, MyTelly, jEdit)
I actually need to play with BottomFeeder again... it's probably been a year since I installed it, but as I've mentioned before, I'm a "serial" aggregator user. :)
Apple actually has very nice Cocoa bindings for Java, and others have contributed decent bindings for Python, too. I guess a lot of the user satisfaction level comes from how well those bindings are implemented. End users accustomed to, say, Cocoa apps written in Objective C will expect all programs to have the features (e.g. Services integration, emacs keybindings, etc.) they're used to, and they generally won't care what the underlying language used to develop it was, as long as the software is featureful, performant, and bugfree.
comments(5) | permanent link | printer friendly | del.icio.us | diggIt | next | prev