GMail in your aggregator

Comment by Vincent Foley

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!)?

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:

1. Fast startup
2. Small footprint
3. Raw performance
4. Tight integration with other applications in the user's environment
5. Native look and feel (not just widget appearance, but consistency wrt key shortcuts, failure-proof cut and paste, etc.)

There are some really nice portable aggregators (Bottomfeeder, nntp//rss, Jaeger, FeedOnFeeds, Sage in Smalltalk, Java, Python, Perl, Javascript/XUL respectively) but I always end up falling back on a really small, fast, slick native app when I'm at home on my Mac, because of the abovementioned issues.

Comment by James Robertson

1. Fast startup - this has nothing to do with Smalltalk, and everything to do with the way I load saved data - and with the way updates get loaded into the app at startup. For the former, the fix is a refactoring of how I do that function. In other words, nothing to do with native/non-native
2. Small footprint - In general, Bf (with a similar number of feeds loaded) will be no heavier than the other popular aggregators. But again, this has to do with the current design, where everything is kept in memory. Again - not related to native/non-native
3. Raw performance - Bf is pretty quick on most operations. Do you have a specific complaint?
4. Tight integration - I could integrate via COM, but I'm not really trying. This doesn't have a lot to do with VW either
5. Native Look/Feel - yes, that's true. But it's the only one of your issues that is related.

As to Mac issues, Bf will be better on the Mac when VW is (within a release or so).

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.

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.